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The\present application is a continuation in part 
of a pending application of Meier et al^, U.S. Serial 
Mo. C&l3 e \&\€£S > filed -October' 30/ 1991 (Attorney £ 
Docket Nos. 92 P 758; DN37882YA) , which is itself a 
continuation iivspart of a pending application of Meier 
et al., U.S. Serial No. 07/769,425, filed October 1, 
1991 (Attorney Docket Nos. 91 P 668; DN37882) . The 
pending application h.S. Serial No. 07/769,425 is also 
a continuation in part: of pending PCT application of 
Mahany et al., Serial No. PCT/US92/08610, filed 
October 1, 1992 (Attorney Docket Nos. 92 P 661; 
DN37882Y) . 

The entire disclosures of each of these 
pending applications including the drawings and 
appendices are incorporated herein by reference as if 
set forth fully in this application. 

Appendix B is a microfiche appendix containing a 
list of the program modules (also included as Appendix 
A) and the program modules themselves\which comprise 
an exemplary computer program listing of the source 
code used by the network controllers and\ntelligent 
base transceivers of the present invent rto. The 
microfiche appendix has ten (10) total microfiche 
sheets and six hundred two (602) total frames. 

BACKGROUND OP THE INVENTION 

In a typical radio data communication system 
having one or more host computers and multiple RF 
terminals, communication between a host computer and 



an RF terminal is provided by one or more base 
stations. Depending upon the application and the 
operating conditions, a large number of these base 
stations may be required to adequately serve the 
5 system. For example, a radio data communication 

system installed in a large factory may require dozens 
of base stations in order to cover the entire factory 
floor. 

In earlier RF (Radio Frequency) data 
10 communication systems, the base stations were 

typically connected directly to a host computer 
through mult i -dropped connections to an Ethernet 
communication line. To communicate between an RF 
terminal and a host computer, in such a system, the RF 
15 terminal sends data to a base station and the base 

O station passes the data directly to the host computer. 

Qj Communicating with a host computer through a base 

y station in this manner is commonly known as hopping. 

m These earlier RF data communication systems used a 

20 single-hop method of communication. 

q In order to cover a larger area with an RF data 

4= communication system and to take advantage of the 

*Z deregulation of the spread-spectrum radio frequencies, 

;fj later-developed RF data communication systems are 

Qj 25 organized into layers of base stations. As in earlier 

RF data communications systems, a typical system 
includes multiple base stations which communicate 
directly with the RF terminals and the host computer. 
In addition, the system also includes intermediate 
30 stations that communicate with the RF terminals, the 

multiple base stations, and other intermediate 
stations. In such a system, communication from an RF 
terminal to a host computer may be achieved, for 
example, by having the RF terminal send data to an 
35 intermediate station, the intermediate station send 
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the data to a base station, and the base station send 
the data directly to the host computer. Communicating 
with a host computer through more than one station is 
commonly known as a multiple-hop communication system. 

Difficulties often arise in maintaining the 
integrity of such multiple-hop RF data communication 
systems. The system must be able to handle both 
wireless and hard-wired station connections, 
efficient dynamic routing of data information, RF 
terminal mobility, and interference from many 
different sources. 
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flT pmiRY OF TH ^ TWVgMTIOH 

The present invention solves many of the problems 
inherent in a multiple-hop data communication system. 
The present invention comprises an RF Local-Area 
Network capable of efficient and dynamic handling of 
data by routing communications between the RF 
Terminals and the host computer through a network of 
intermediate base stations. 

In one embodiment of the present invention, the 
RF data communication system contains one or more host 
computers and multiple gateways, bridges, and RF 
terminals. Gateways are used to pass messages to and 
from a host computer and the RF Network. A host port 
is used to provide a link between the gateway and the 
host computer. In addition, gateways may include 
bridging functions and may pass information from one 
RF terminal to another. Bridges are intermediate 
relay, nodes which repeat data messages. Bridges can 
repeat data to and from bridges, gateways and RF 
terminals and are used to extend the range of the 
gateways . 

The RF terminals are attached logically to the 
host computer and use a network formed by a gateway 
and the bridges to communicate with the host computer. 
To set up the network, an optimal configuration for 
conducting network communication spanning tree is 
created to control the flow of data communication. To 
aid understanding by providing a more visual 
description, this configuration is referred to 
hereafter as a "spanning tree- or "optimal spanning 
tree" . 

Specifically, root of the spanning tree are the 
gateways; the branches are the bridges; and non- 
bridging stations, such as RF terminals, are the 
leaves of the tree. Data are sent along the branches 



- 5 - 



10 



fn 



15 



of the newly created optimal spanning tree. Nodes in 
the network use a backward learning technique to route 
packets along the correct branches. 

One object of the present invention is to route 
data efficiently, dynamically, and without looping. 
Another object of the present invention is to make the 
routing of the data transparent to the RF terminals. 
The RF terminals, transmitting data intended for the 
host computer, are unaffected by the means ultimately 
used by the RF Network to deliver their data. 

It is a further object of the present invention 
for the network to be capable of handling RF terminal 
mobility and lost nodes with minimal impact on the 
entire RF data communication system. 
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FIG^/lTls a functional block diagram of an RF 
data communication system incorporating the RF local- 
area network of^T^resent invention. 

FIG^rTTflow diagram illustrating a bridging 
node's instruction and maintenance of the spanning 
tree. 
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FIG. 1 is a functional block diagram of an RF 
data communication system. In one embodiment of the 
present invention, the RF data communication system 
has a host computer 10, a network controller 14 and 
bridges 22 and 24 attached to a data communication 
link 16. Also attached to the data communication link 
16 is a gateway 20 which acts as the root node for the 
spanning tree of the RF data network of the present 
invention. A bridge 42 is attached to the gateway 20 
through a hard-wired communication link and bridges 40 
and 44 are logically attached to gateway 20 by two 
independent RF links. Additional bridges 46, 48, 50 
and 52 are also connected to the RF Network and are 
shown in the FIG. 1. Note that, although shown 
separate from the host computer 10, the gateway 20 
(the spanning tree root node) may be part of host 
computer 10. 

The FIG. 1 further shows RF terminals 100 and 102 
attached to bridge 22 via RF links and RF terminal 104 
attached to bridge 24 via an RF link. Also, RF 
terminals 106, 108, 110, 112, 114, 116, 118, and 120 
can be seen logically attached to the RF Network 
through their respective RF links. The RF terminals 
in FIG. 1 are representative of non-bridging stations. 
In alternate embodiments of the present invention, the 
RF Network could contain any type of device capable of 
supporting the functions needed to communicate in the 
RF Network such as hard-wired terminals, remote 
printers, stationary bar code scanners, or the like. 
The RF data communication system, as shown in FIG. l, 
represents the configuration of the system at a 
discrete moment in time after the initialization of 
the system. The RF links, as shown, are dynamic and 
subject to change. For example, changes in the 



structure of the RF data communication system can be 
caused by movement of the RF terminals and by 
interference that affects the RF communication links. 

in the preferred embodiment, the host computer 10 
is an IBM 3090, the network controller 14 is a model 
RC3250 of the Norand Corporation, the data 
communication link 16 is an Ethernet link, the 
nodes 20, 22, 24, 40, 42, 44, 46, 48, 50 and 52 are 
intelligent base transceiver units of the type RB4000 
of the Norand Corporation, and the RF terminals 100, 
102, 104, 106, 108, 110, 112, 114, 116, 118 and 120 
are of type RT1100 of the Norand Corporation. 

The optimal spanning tree, which provides the 
data pathways throughout the communication system, is 
stored and maintained by the network as a whole. Each 
node in the network stores and modifies information 
which specifies how local communication traffic should 
flow. optimal spanning trees assure efficient, 
' adaptive (dynamic) routing of information without 
looping. 

To initialize the RF data communication system, 
the gateway 20 and the other nodes are organized into 
an optimal spanning tree rooted at the gateway 20. To 
form the optimal spanning tree, in the preferred 
embodiment the gateway 20 is assigned a status of 
ATTACHED and all other bridges are assigned the status 
UNATTACHED . The gateway 20 is considered attached to 
the spanning tree because it is the root node^ 
initially, all other bridges are unattached and lack 
a parent in the spanning tree. At this point, the 
attached gateway node 20 periodically broadcasts a 
specific type of polling packet referred to hereafter 
as "HELLO packets". The HELLO packets can be 
broadcast using known methods of communicating via 
radio frequency (RF) link or via a direct wire link. 



in the preferred embodiment of the present invention, 
the RF link is comprised of spread-spectrum 
transmissions using a polling protocol. Although a 
polling protocol is preferred, a carrier-sense 
multiple-access (CSMA) , busy-tone, or any other 
protocol might also manage the communication traffic 

on the RF link. 

HELLO packets contain 1) the address of the 
sender, 2) the hopping distance that the sender is 
from the root, 3) a source address, 4) a count of 
nodes in the subtree which flow through that bridge, 
and 5) a list of system parameters. Each node in the 
network is assigned a unique network service address 
and a node-type identifier to distinguish between 
different nodes and different node types. The 
distance of a node from the root node is measured in 
hops times the. bandwidth of each hop. The gateway 
root is considered to be zero hops away from itself. 

FIG. 2 is a flow diagram illustrating a bridge's 
participation in the construction and maintenance of 
the spanning tree. At a block 201, the bridge begins 
the local construction of the spanning tree upon 
power-up. Next, at a block 203, the bridge enters the 
UNATTACHED state, listening for HELLO packets (also 
referred to as HELLO messages herein) that are 
broadcast. 

By listening to the HELLO messages, bridges can 
learn which nodes are attached to the spanning tree. 
At a block 205, the bridge responds to a HELLO packet 
received by sending an ATTACH. request packet to the 
device that sent the received HELLO packet. The 
ATTACH. request packet is thereafter forwarded towards 
and to the root node which responds by sending an 
ATTACH. response packet back down towards and to the 
bridge. 



\0 



- 10 - 

The bridge awaits the ATTACH . response packet at 
a block 207. Upon receipt of the ATTACH. response 
packet, at a block 209, the bridge enters an ATTACHED 
state. Thereafter, at a block 211, the bridge begins 
periodically broadcasting HELLO packets and begins 
forwarding or relaying packets received. 
Specifically, between HELLO packet broadcasts, the 
bridge listens for HELLO, DATA, ATTACH. request and 
ATTACH. response packets broadcast by other devices in 
the communication network. Upon receiving such a 
packet, the bridge branches to a block 213. At the 
block 213, if the bridge detects that it has become 
detached from the spanning tree the bridge will branch 
back to the block 203 to establish attachment. Note 
that although the illustration in FIG. 2 places block 
213 immediately after the block 211, the bridges 
functionality illustrated in block 213 is actually 
distributed throughout the flow diagram. 

if at the block 213 detachment has not occurred, 
at a block 214, the bridge determines if the received 
packet is a HELLO packet. If so, the bridge analyzes 
the contents of the HELLO packet at a block 215 to 
determine whether to change its attachment point in 
the spanning tree. In a preferred embodiment, the 
bridge attempts to maintain attachment to the spanning 
tree at the node that is logically closest to the root 
node. 

The logical distance, in a preferred embodiment, 
is based upon the number of hops needed to reach the 
root node and the bandwidth of those hops. The 
distance the attached node is away from the root node 
is found in the second field of the HELLO message that 
is broadcast. In another embodiment of the present 
invention, the bridges consider the number of nodes 
attached to the attached node as well as the logical 



distance of the attached node from the root node. If 
an attached node is overloaded with other attached 
nodes, the unattached bridge may request attachment to 
the less loaded node, or to a more loaded node as 
described above in networks having regions of 
substantial RF overlap. In yet another embodiment, to 
avoid instability in the spanning tree, the bridge 
would only conclude to change attachment if the 
logical distance of the potential replacement is 
greater than a threshold value. 

If no change in attachment is concluded, at a 
block 217 the bridge branches back to the block 211. 
If a determination is made to change attachment, a 
DETACH packet is sent to the root as illustrated at a 
block 219. After sending the DETACH packet, the 
bridge branches back to the block 205 to attach to the 
new spanning tree node. Note that the order of shown 
for detachment and attachment is only illustrative and 

can be reversed. 

Referring back to the block 214, if the received 
packet (at block 211) is not a HELLO packet, the 
bridge branches to a block 221 to forward the received 
packet through the spanning tree. Afterwards, the 
bridge branches back to the block 211 to continue the 
process. 

specifically, once attached, the attached bridge 
begins broadcasting HELLO packets (at the block 211) 
seeking to have all unattached bridges (or other 
network devices) attach to the attached bridge. Upon 
receiving an ATTACH . request packet, the bridge 
forwards that packet toward the root node (through the 
blocks 211, 213, 214 and 221. On its path toward the 
root, each node records the necessary information of 
how to reach requesting bridge. This process is 
called "backward learning" herein, and is discussed 
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»«. „ result of the backward 
more fully below. As a result 

„™ the root node receives the 
learning, once tne root 

ATTACH . request packet, an ATTACH, response pac ket can 
be sent through the spanning tree to the bridge 
requesting attachment. 

After attaching to an attached node, the newly 
attached bridge (the child, must determine its 
distance from the root node. To 
distance of the child from the root node, the child 
adds the broadcast distance of its parent from the 
root nod. to the distance of th. child from its 
parent. In the preferred embodiment, th. distance of 
a child from it. parent is bas* on the bandwidth of 
the data communication link. For example, if th. 
child attache, to its parent via a ^d-wir.d link 
(data rat. 26,000 baud), th.n th. distance of that 
communication link might equal, for example, on. hop_ 
How.v.r, if the child attache, to it. parent via an 
link (data rat. 9600 baud), th.n th. distance of that 
communication linK might correspondingly be equal 3 
hops. Th. number of th. hop corr.sponds directly to 
the communication sp..d of the lime. This may not 
only tak. into consid.ration baud rate, but also such 
factors as channel interference. 

initially, only th. root gateway node 20 is 
broadcasting HELLO message, and only nodes 40, 42 
.„.■« ,„„ 0 f th. HELLO messages 
and 44 are within range or m» 
broadcast by the gateway. Therefore, after the 
listening period has expired, nodes 40 42 and 44 
request attachment to the gateway node 20. The 
Leached nodes 40, 42, and 44 send ™""^ 
packets and the attached gateway node 20 acknowledges 
L ATTACH.request packets with local ^"-^ 
packets. The newly attached bridges are 
status ATTACHED and begin broadcasting their own HELLO 
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packets, looking for other unattached bridges. Again, 
the remaining unattached nodes attempt to attach to 
the attached nodes that are logically closest to the 
root node. For example, node 48 is within range of 
HELLO messages from both nodes 40 and 42. However, 
node 40 is three hops, via an RF link, away from the 
gateway root node 20 and node 42 is only one hop, via 
a hard-wired link, away from the gateway root node 20. 
Therefore, node 48 attaches to node 42, the closest 
node to the gateway root node 20. 

The sending of HELLO messages, ATTACH . request 
packets and ATTACH. confirm packets continues until the 
entire spanning tree is established. In addition, 
attached bridges may also respond to HELLO messages. 
If a HELLO message indicates that a much closer route 
to the root node is available, the attached bridge 
sends a DETACH packet to its old parent and an 
ATTACH.request packet to the closer node. To avoid 
instability in the system and to avoid overloading any 
given node, an attached bridge would only respond to 
a HELLO message if the hop count in a HELLO packet is 
greater than a certain threshold value, 
CHANGE.THRESHOLD. In the preferred embodiment, the 
value of the CHANGE THRESHOLD equals 3. In this 
manner, an optimal spanning tree is formed that is 
capable of transmitting data without looping. 

Nodes, other than the gateway root node, after 
acknowledging an ATTACH.request packet from a 
previously unattached node, will send the 
ATTACH.request packet up the branches of the spanning 
tree to the gateway root node. As the ATTACH.request 
packet is being sent to the gateway root node, other 
nodes attached on the same branch record the 
destination of the newly attached node in their 
routing entry table. When the ATTACH.request packet 
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reaches the gateway root node, the gateway root node 
returns an end-to-end ATTACH. confirm packet. 

After the spanning tree is initialized, the RF 
terminals listen for periodically broadcasted Hello 
packets to determine which attached nodes are in 
range. After receiving HELLO messages from attached 
nodes, an RF terminal responding to an appropriate 
poll sends an ATTACH . request packet to attach to the 
node logically closest to the root. For example, RF 
terminal 110 is physically closer to node 44. 
However, node 44 is three hops, via an RF link, away 
from the gateway root node 20 and node 42 is only one 
hop, via a hard-wired link, away from the gateway root 
node 20. Therefore, RF terminal 110, after hearing 
HELLO messages from both nodes 42 and 44, attaches to 
node 42, the closest node to the gateway root node 20. 
Similarly, RF terminal 114 hears HELLO messages from 
nodes 48 and 50. Nodes 48 and 50 are both four hops 
away from the gateway root node 20. However, node 48 
has two RF terminals 110 and 112 already attached to 
it while node 50 has only one RF terminal 116 attached 
to it. Therefore, RF terminal 114 will attach to 
node 50, the least busy node of equal distance to the 
gateway root node 20. Attaching to the least busy 
node proves to be the most efficient practice when the 
communication system has little overlap in the RF 
communication regions. In another embodiment, 
however, instead of attaching to the I"* node 
of equal distance to the gateway root node 20, the 
attachment is established with the busiest node. 

The attached node acknowledges the ATTACH, request 
and sends the ATTACH . request packet to the gateway 
root node. Then, the gateway root node returns an 
end-to-end ATTACH. confirm packet. In this manner, the 
end-to-end ATTACH. request functions as a discovery 
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packet enabling the gateway root node, and all other 
nodes along the same branch, to learn the address of 
the RF terminal quickly. This process is called 
backward learning. Nodes learn the addresses of 
terminals by monitoring the traffic from terminals to 
the root. If a packet arrives from a terminal that is 
not contained in the routing table of the node, an 
entry is ^ made in the routing table. The entry 
includes the terminal address and the address of the 
node that sent the packet. In addition, an entry 
timer is set for that terminal. The entry timer is 
used to determine when RF terminals are actively using 
the attached node. Nodes maintain entries only for 
terminals that are actively using the node for 
communication. If the entry timer expires due to lack 
of communication, the RF terminal entry is purged from 

the routing table. 

The RF links among the RF terminals, the bridges, 
and the gateway are often lost. Therefore, a 
connection-oriented data-link service is used to 
maintain the logical node-to-node links. In the 
absence of network traffic, periodic messages are sent 
and received to ensure the stability of the RF link 
As a result, the loss of a link is quickly detected 
and the RF Network can attempt to establish a new RF 
link before data transmission from the host computer 
to an RF terminal is adversely affected. 

Communication between terminals and the host 
computer is accomplished by using the resulting RF 
Network. To communicate with the host computer, an RF 
terminal sends a data packet in response to a poll 
from the bridge closest to the host computer 
Typically, the RF terminal is attached to the bridge 
cTosest to the host computer. However, RF terminal 
are constantly listening for HELLO and pollinc 
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. p»™ other bridges and may attach to, and 
massages from otner i „. kl » „« 

• ... ui*h a bridge in the table of 
then communicate with, a onog „._4„«i 
bridges that is closer to the particular RF terminal 

under certain operating conditions, duplicate 
data packets can be transmitted in the RF Xetwork. 
K or example, it is possible for an RF terminal to 
transmit a data packet to its attached node, tor the 
node to transmit the acknowledgement frame, and for 

the RF terminal not to ^ u 

Under such circumstances, the RF termina 
retransmit the data. If the duplicate data packet is 
updated into the database of the host «-P* a ^«£ 
database would become corrupt. Therefore the RF 
H.twork of the present invention detects duplicate 
data packets. To ensure data integrity, -* 
data transmissions receives a sequence number The 
sequence numbers are continuously incremented, and 
duplicate sequence numbers are not accepted. 

When a bridge receives a data packet from a 
terminal directed to the host computer, the bridge 

forwards the data packet to the parent node on the 

branch. The parent node then forwards the data packet 

to its parent node. The forwarding of the data packet 

continue, until the gateway root nod. 

data P ack.t and sends it to th. host computer. 

data pac* „„v-t arrives at a node from the 

Similarly, when a packet arrives 

host computer directed to an RF terminal, the node 
cLks its routing entry table and 

oacket to its child node which is along the branch 
destine! for the RF terminal. It is not necessary for 

tdes *. »—> Mi ^^;z::r^ 

to know the ultimate location of the RF terminal The 
forwarding of th. data packet continues until the data 
pacTet Reaches th. final nod. on the branch, which 
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then forwards the data packet directly to the terminal 
itself. 

Communication is also possible between RF 
terminals. To communicate with another RF terminal, 
the RF terminal sends a data packet to its attached 
bridge. When the bridge receives the data packet from 
a terminal directed to the host computer, the bridge 
checks to see if the destination address of the RF 
terminal is located within its routing table. If it 
is, the bridge simply sends the message to the 
intended RF terminal. If not, the bridge forwards the 
data packet to its parent node. The forwarding of the 
data packet up the branch continues until a common 
parent between the RF terminals is found. Then, the 
common parent (often the gateway node itself) sends 
the data packet to the intended RF terminal via the 
branches of the RF Network. 

During the normal operation of the RF Network, RF 
: terminals can become lost or unattached to their 
attached node. If an RF terminal becomes unattached, 
for whatever reason, its routing entry is purged and 
the RF terminal listens for HELLO or polling messages 
from any attached nodes in range. After receiving 
HELLO or polling messages from attached nodes, the RF 
terminal sends an ATTACH. request packet to the 
attached node closest to the root. That attached node 
acknowledges the ATTACH. request and sends the 
ATTACH. request packet onto the gateway root node. 
Then, the gateway root node returns an end-to-end 
ATTACH. confirm packet. 

Bridges can also become lost or unattached during 
normal operations of the RF Network. If a bridge 
becomes lost or unattached, all routing entries 
containing the bridge are purged. The bridge then 
broadcasts a HELLO. request with a global bridge 
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destination address. Attached nodes will broadcast 
HELLO packets immediately if they receive an 
ATTACH. request packet with a global destination 
address. This helps the lost node re-attach. Then, 
the bridge enters the LISTEN state to learn which 
attached nodes are within range. The unattached 
bridge analyzes the contents of broadcast HELLO 
messages to determine whether to request attachment to 
the broadcasting node. Again, the bridge attempts to 
attach to the node that is logically closest to the 
root node. After attaching to the closest node, the 
bridge begins broadcasting HELLO messages to solicit 
ATTACH. requests from other nodes or RF terminals. 

The spread-spectrum system provides a 
hierarchical radio frequency network of on-line 
terminals for data entry and message transfer in a 
mobile environment. The network is characterized by 
sporadic data traffic over multiple-hop data paths 
consisting of RS485 or ethernet wired links and 
single-channel direct sequenced spread spectrum links. 
The network architecture is complicated by moving, 
hidden, and sleeping nodes. The spread spectrum 
system consists of the following types of devices: 

Terminal controller -- A gateway which passes 
messages from a host port to the RF network; and which 
passes messages from the network to the host por^ 
The host port (directly or indirectly) provides a link 
between the controller and a -.host" computer to which 
the terminals are logically attached. 

Base station - An intermediate relay node which 
is used to extend the range of the controller node. 
Base station-to-controller or base station-to-base 
station links can be wired or wireless RF. 
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Terminal ~ Norand RF hand-held terminals, 
printers, etc. In addition, a controller device has 
a terminal component. 

The devices are logically organized as nodes in 
an (optimal) spanning tree, with the controller at the 
root, internal nodes in base stations or controllers 
on branches of the tree, and terminal nodes as 
(possibly mobile) leaves on the tree. Like a sink 
tree, nodes closer to the root of the spanning tree 
are said to be "downstream" from nodes which are 
further away. Conversely, all nodes are "upstream" 
from the root. Packets are only sent along branches 
of the spanning tree. Nodes in the network use a 
"BACKWARD LEARNING" technique to route packets along 
the branches of the spanning tree. 

Devices in the spanning tree are logically 
categorized as one of the following three node types: 

1) Root (or root bridge) - A controller device 
which functions as the root bridge of the 
network spanning tree. In the preferred 
embodiment, the spanning tree has a single root 
node. initially, all controllers are root 
candidates from which a root node is selected. 
This selection may be based on the hopping 
distance to the host, preset priority, random 
selection, etc. 

2) Bridge - An internal node in the spanning 
tree which is used to "bridge" terminal nodes 
together into an interconnected network. The 
root node is also considered a bridge and the 
term "bridge" may be used to refer to all non- 
terminal nodes or all non-terminal nodes except 
the root, depending on the context herein. A 
bridge node consists of a network interface 
function and a routing function. 
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3) Terminal - leaf node in the spanning tree. 
A terminal node can be viewed as the software 
entity that terminates a branch in the spanning 
tree. 

A controller device contains a terminal node(s) 
and a bridge node. The bridge node is the root node 
if the controller is functioning as the root bridge. 
A base station contains a bridge node. A terminal 
device contains a terminal node and must have a 
network interface function. A "bridging entity" 
refers to a bridge node or to the network interface 
function in a terminal. 

The basic requirements of the system are the 
following. 

a) Wired or wireless node connections. 

b) Network layer transparency. 

c) Dynamic/automatic network routing 
configuration. 

d) Terminal mobility. Terminals should be able 
to move about the RF network without losing an end-to* 
end connection. 

e) Ability to accommodate sleeping terminals. 

f) Ability to locate terminals quickly. 

g) Built-in redundancy. Lost nodes should have 
minimal impact on the network. 

h) Physical link independence. The bridging 
algorithm is consistent across heterogeneous physical 
links. 

The software for the spread-spectrum system is 
functionally layered as follows. 

Medium Access Control (MAC) 

The MAC layer is responsible for providing 
reliable transmission between any two nodes in the 
network (i.e. terminal-to-bridge). The MAC has a 

£1 



channel access control component and a link control 
component. The link control component facilitates and 
regulates point-to-point frame transfers in the 
absence of collision detection. The MAC channel 
access control component regulates access to the 
network. Note that herein, the MAC layer is also 
referred to as the Data Link layer. 

Bridging Laver 

The bridging layer, which is also referred to 
herein as the network layer, has several functions as 
follows. 

1. The bridging layer uses a "HELLO protocol" 
to organize nodes in the network into an optimal 
spanning tree rooted at the root bridge. The spanning 
tree is used to prevent loops in the topology. 
Interior branches of the spanning tree are relatively 
stable (i.e. controller and relay stations do not move 
often). Terminals, which are leaves on the spanning 
three, may become unattached, and must be reattached, 
frequently. 

2. The bridging layer routes packets from 
terminals to the host, from the host to terminals, and 
from terminals to terminals along branches of the 
spanning tree. 

3. The bridging layer provides a service for 
storing packets for SLEEPING terminals. Packets which 
cannot be delivered immediately can be saved by the 
bridging entity in a parent node for one or more HELLO 
times. 

4. The bridging layer propagates lost node 
information throughout the spanning tree. 

5. The bridging layer maintains the spanning 
tree links. 



6. The bridging layer distributes network 
interface addresses. 

Logical Link Control Laver 

A logical link control layer, also known herein 
as the Transport layer herein, is responsible for 
providing reliable transmission between any two nodes 
in the network (i.e., terminal-to-base station). The 
data-link layer provides a connection-oriented 
reliable service and a connectionless unreliable 
service. The reliable service detects and discards 
duplicate packets and retransmits lost packets. The 
unreliable services provides a datagram facility for 
upper layer protocols which provide a reliable end-to- 
end data path. The data- link layer provides ISO layer 
2 services for terminal-to-host application sessions 
which run on top of an end-to-end terminal-to-host 
transport protocol. However, the data- link layer 
provides transport (ISO layer 4) services for sessions 
contained within the SST network. 

Higher tayeys 

For terminal-to-terminal sessions contained 
within the SST network, the data- link layer provides 
transport layer services and no additional network or 
transport layer is required. In this case, the MAC, 
bridging, and data-link layers discussed above can be 
viewed as a data-link layer, a network layer, and a 
transport layer, respectively. For terminal-to-host- 
application sessions, higher ISO layers exist on top 
of the SST data-link layer and must be implemented in 
the terminal and host computer, as required. This 
document does not define (or restrict) those layers. 
This document does discuss a fast-connect VMTP-like 



transport protocol which is used for transient 
internal terminal-to-terminal sessions. 

Specifically, a network layer has several 
functions, as follows. 

1) The network layer uses a "hello protocol" to 
organize nodes in the network into an optimal spanning 
tree rooted at the controller. (A spanning tree is 
required to prevent loops in the topology.) Interior 
branches of the spanning tree are relatively stable 
(i.e., the controller and base stations do not move 
often) . Terminals, which are leaves on the spanning 
tree, become unattached, and must be reattached 
frequently. 

2) The network layer routes messages from 
terminals to the host, from the host to terminals, and 
from terminals to terminals along branches of the 
spanning tree. 

3) The network layer provides a service for 
storing messages for SLEEPING terminals. Messages 
which cannot be delivered immediately can be saved by 
the network entity in a parent node for one or more 
hello times. 

4) The network layer propagates lost node 
information throughout the spanning tree. 

5) The network layer maintains the spanning 
tree links in the absence of regular data traffic. 

A transport layer is responsible for establishing 
and maintaining a reliable end-to-end data path 
between transport access points in any two nodes in 
the network. The transport layer provides unreliable, 
reliable and a transaction-oriented services. The 
transport layer should be immune to implementation 
changes in the network layer. 

The responsibilities of the transport layer 
include the following. 



1) Establishing and maintaining TCP-like 
connections for reliable root-to-terminal data 
transmission. 

2) Maintaining VMTP-like transaction records 
for reliable transient message passing between any two 
nodes. 

3) Detecting and discarding duplicate packets. 

4) Retransmitting lost packets. 

Layers 1 through 4 are self-contained within the 
Nor and RF network, and are independent of the host 
computer and of terminal applications. The session 
layer (and any higher layers) are dependent on 
specific applications. Therefore f the session 
protocol (and higher protocols) must be implemented as 
required. Note that a single transport access point 
is sufficient to handle single sessions with multiple 
nodes. Multiple concurrent sessions between any two 
nodes could be handled with a session identifier in a 
session header. 

Network address requirements are as follows. DLC 
framed contain a hop destination and source address in 
the DLC header, network packets contain an end-to-end 
destination and a source address in the network 
header. Transport messages do not contain an address 
field; instead , a transport connection is defined by 
network layer source and destination address pairs. 
Multiple transport connections require multiple 
network address pairs. 

The transport header contains a TRANSPORT ACCESS 
POINT identifier. DLC and network addresses are 
consistent and have the same format. Each node has a 
unique LONG ADDRESS which is programmed into the node 
at the factory. The long address is used only to 
obtain a SHORT ADDRESS from the root node. 
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The network entity in each node obtains a SHORT 
ADDRESS from the root node, which identifies the node 
uniquely. The network entity passes the short address 
to the DLC entity. Short addresses are used to 
minimize packet sizes* 

Short addresses consist of the following ♦ There 
is: an address length bit (short or long) . 

a spanning tree identified. 

a node-type identifier. Node types are well 
known. 

a unique multi-cast or broadcast node identifier. 

The node-identifier parts of root addresses are 
well known and are constant. A default spanning tree 
identifier is well known by all nodes. A non-default 
spanning tree identifier can be entered into the root 
node (i.e. , by a network administrator) and advertised 
to all other nodes in "hello" packets. The list of 
non-default spanning trees to which other nodes can 
attach must be entered into each node. 

A node-type identifier of all l's is used to 
specify all node types. A node identifier of all l's 
is used to specify all nodes of the specified type. 
A DLC identifier of all O's is used to specify a DLC 
entity which does not yet have an address. The all- 
O's address is used in DLC frames that are used to 
send and receive network ADDRESS packets. (The 
network entity in each node filters ADDRESS packets 
based on the network address.) 

Short-address allocation is accomplished as 
follows. Short node identifiers of root nodes are 
well known. All other nodes must obtain a short node 
identifier from the root. To obtain a short address, 
a node send an ADDRESS request packet to the root 
node. The source addresses (i.e., DLC and network) in 
the request packet are LONG ADDRESSES. The root 
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maintains an address queue of used and unused SHORT 
ADDRESSES. If possible, the root selects an available 
short address, associates the short address with the 
long address of the requesting node, and returns the 
short address to the requesting node in an ADDRESS 
acknowledge packet. (Note that the destination 
address in the acknowledge packet is a long address.) 

A node must obtain a (new) short address 
initially and whenever an ADDRESS-TIMEOUT inactivity 
period expires without having the node receive a 
packet from the network entity in the root. 

The network entity in the root maintains 
addresses in the address queue in least recently used 
order. Whenever a packet is received, the source 
address is moved to the end of the queue. The address 
at the head of the queue is available for use by a 
requesting node if it has never been used or if it has 
been inactive for a MAX-ADDRESS-LIFE time period. 

MAX-ADDRESS-LIFE must be larger than ADDRESS- 
TIMEOUT to ensure that an address is not in use by any 
node when it becomes available for another node. If 
the root receives an ADDRESS request from a source for 
which an entry exists in the address queue, the root 
simply updates the queue and returns the old address. 

The network layer organizes nodes into an optimal 
spanning tree with the controller at the root of the 
tree. (Note that the spanning three identifier allows 
two logical trees to exist in the same coverage area.) 
Spanning tree organization is facilitated with a HELLO 
protocol which allows nodes to determine the shortest 
path to the root before attaching to the spanning 
tree. All messages are routed along branches of the 
spanning tree. 

Nodes in the network are generally categorized as 
ATTACHED or UNATTACHED. Initially, only the root node 
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is attached. A single controller may be designated as 
the root, or multiple root candidates (i.e. 
controllers) may negotiate to determine which node is 
the root. Attached bridge nodes and root candidates 
transmit "HELLO" packets at calculated intervals. The 
HELLO packets include: 

a) the source address, which includes the 
spanning tree ID) . 

b) a broadcast destination address. 

c) a "seed" value from which the time schedule 
of future hello messages can be calculated. 

d) a hello slot displacement time specifying an 
actual variation that will occur in the scheduled 
arrival of the very next hello message (the scheduled 
arrival being calculated from the "seed") . 

e) the distance (i.e., path cost) of the 
transmitter from the host. The incremental portion of 
the distance between a node and its parent is 
primarily a function of the type of physical link 
(i.e., ether net, RS485, RP, or the like). If a 
signal-strength indicator is available, connections 
are biased toward the link with the best signal 
strength. The distance component is intended to bias 
path selection toward (i.e., wired) high-speed 
connections. Setting a minimum signal strength 
threshold helps prevent sporadic changes in the 
network. In addition, connections can be biased to 
balance the load (i.e., the number of children) on a 
parent node. 

f ) a pending message list. Pending message lists 
consist of 0 or more destination-address/message- 
length pairs. Pending messages for terminals are 
stored in the terminal's parent node. 

g) a detached-node list. Detached-node lists 
contain the addresses of nodes which have detached 



from the spanning tree. The root maintains two lists. 
A private list consists of all detached node 
addresses, and an advertised list consists of the 
addresses of all detached nodes which have pending 
transport messages. The addresses in the hello packet 
are equivalent to the advertised list. 

An internal node learns which entries should be 
in its list from hello messages transmitted by its 
parent node. The root node builds its detached-node 
lists from information received in DETACH packets. 
Entries are included in hello messages for DETACH-MSG- 
LIFE hello times. 

Attached notes broadcast "SHORT HELLO" messages 
immediately if they receive an "HELLO. request" packet 
with a global destination address; otherwise, attached 
nodes will only broadcast hello messages at calculated 
time intervals in "hello slots." Short hello messages 
do not contain a pending-message or detached-node 
list. Short hello messages are sent independently of 
regular hello messages and do not affect regular hello 
timing. 

Unattached nodes (nodes without a parent in the 
spanning tree) are, initially, in an "UNATTACHED 
LISTEN" state. During the listen state, a node learns 
which attached base station/controller is closest to 
the root node by listening to hello messages. After 
the listening period expires an unattached node sends 
an ATTACH .request packet to the attached node closest 
to the root. The attached node immediately 
acknowledges the ATTACH .request, and send the 
ATTACH. request packet onto the root (controller) node. 
The root node returns the request as an end-to-end 
ATTACH. confirm packet. If the newly-attached node is 
a base station, the node calculates its link distance 
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and adds the distance to the distance of its parent 
before beginning to transmit hello messages. 

The end-to-end ATTACH. request functions as a 
discovery packet, and enables the root node to learn 
the address of the source node quickly. The end-to- 
end ATTACH, request , when sent from a node to the 
root, does not always travel the entire distance. 
When a downstream node receives an ATTACH. request 
packet and already has a correct routing entry for the 
associated node, the downstream node intercepts the 
request and returns the ATTACH. confirm to the source 
node. (Note that any data piggy-backed on the 
ATTACH. request packet must still be forwarded to the 
host.) This situation occurs whenever a "new" path 
has more than one node in common with the "old" path. 

The LISTEN state ends after MIN_HELLO hello time 
slots if hello messages have been received from at 
least one node. If no hello messages have been 
received the listening node waits and retries later. 

An attached node may respond to a hello message 
from a node other than its parent (i.e., with an 
ATTACH. request) if the difference in the hop count 
specified in the hello packet exceeds a CHANGE- 
THRESHOLD level. 

Unattached nodes may broadcast a GLOBAL 
ATTACH .request with a multi-cast base station 
destination address to solicit short hello messages 
from attached base stations. The net effect is that 
the LISTEN state may (optionally) be shortened. (Note 
that only attached base station or the controller may 
respond to ATTACH, requests.) Normally, this facility 
is reserved for base stations with children and 
terminals with transactions in progress. 

ATTACH, requests contain a (possibly empty) CHILD 
LIST, to enable internal nodes to update their routing 
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tables. ATTACH. requests also contain a "count" field 
which indicates that a terminal may be SLEEPING. The 
network entity in the parent of a SLEEPING terminal 
con temporarily store messages for later delivery. If 
the count field is non-zero , the network entity in a 
parent node will store pending messages until 1) the 
message is delivered, or 2) "count" hello times have 
expired. 

Transport layer data can be piggy-backed on an 
attached request packet from a terminal. (i.e., an 
attach request/ confirm can be implemented with a bit 
flag in the network header of a data packet.) 

Network layer routing. 

All messages are routed along branches of the 
spanning tree. Base stations "learn" the address of 
terminals by monitoring traffic from terminals (i.e., 
to the root). When a base station receives (i.e., an 
ATTACH. request) packet, destined for the root, the 
base station creates or updates an entry in its 
routing table for the terminal. The entry includes 
the terminal address, and the address of the base 
station which sent the packet (i.e., the hop address) . 
When a base station receives an upstream packet (i.e., 
from the root, destined for a terminal) the packet is 
simply forwarded to the base station which is in the 
routing entry for the destination. Upstream messages 
(i.e., to a terminal) are discarded whenever a routing 
entry does not exist. Downstream messages (i.e., from 
a terminal to the root) are simply forwarded to the 
next downstream node (i.e., the parent in the branch 
of the spanning tree. 

TERMINAL-TO-TERMINAL COMMUNICATIONS is 
accomplished by routing all terminal-to-terminal 
traffic through the nearest common ancestor. In the 
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worst case, the root is the nearest common ancestor. 
A "ADDRESS SERVER" facilitates terminal-to-terminal 
communications (see below) . 

DELETING INVALID ROUTING TABLE ENTRIES is 
accomplished in several ways: connection oriented 
transport layer ensures that packets will arrive from 
nodes attached to the branch of the spanning tree 
within the timeout period, unless a node is 
disconnected, ) 

2) Whenever the DLC entity in a parent fails 
RETRY MAX times to send a message to a child node, the 
node is logically disconnected from the spanning tree, 
with one exception. If the child is a SLEEPING 
terminal, the message is retained by the network 
entity in the parent for "count" hello times* The 
parent immediately attempts to deliver the message 
after it sends its next hello packet. If, after 
"count" hello times, the message cannot be delivered, 
then the child is logically detached from the spanning 
tree. Detached node information is propagated 
downstream to the root node, each node in the path of 
the DETACH packet must adjust its routing tables 
appropriately according to the following rules: a) if 
the lost node is a child terminal node, the routing 
entry for the terminal is deleted and a DETACH packet 
is generated, b) if the node specified in DETACH 
packet is a terminal and the node which delivered the 
packet is the next hop in the path to the terminal, 
then the routing table entry for the terminal is 
deleted and the DETACH packet is forwarded, c) if the 
lost node is a child base station node then all 
routing entries which specify that base station as the 
next hop are deleted and a DETACH packet is generated 
for each lost terminal. 
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IN GENERAL, WHENEVER A NODE DISCOVERS THAT A 
TERMINAL IS DETACHED, IT PURGES ITS ROUTING ENTRY FOR 
THE TERMINAL. WHENEVER A NODE DISCOVERS THAT A BASE 
STATION IS DETACHED, IT PURGES ALL ROUTING ENTRIES 
CONTAINING THE BASE STATION. ONLY ENTRIES FOR 
UPSTREAM NODES ARE DELETED. 

When DETACH packets reach the root node, they are 
added to a "detached list." Nodes remain in the root 
node's detached list until a) the node reattaches to 
the spanning tree, or b) the list entry times out. 
The detached list is included in hello messages and is 
propagated throughout the spanning tree. 

For example, if a terminal detaches and 
reattaches to a different branch in the spanning tree, 
all downstream nodes in the new branch (quickly) 
"learn" the new path to the terminal. Nodes which 
were also in the old path change their routing tables 
and no longer forward packets along the old path. At 
least one node, the root, must be in both the old and 
new path. A new path is established as soon as an 
end-to-end attach request packet from the terminal 
reaches a node which was also in the old path. 

4) A node (quickly) learns that it is detached 
whenever it receives a hello message, from any node, 
with its address in the associated detached list. The 
detached node can, optionally, send a global 
ATTACH. request, and then enters the UNATTACHED LISTEN 
state and reattaches as described above. After 
reattaching, the node must remain in a HOLD-DOWN state 
until its address is aged out of all detached lists. 
During the HOLD-DOWN state the node ignores detached 
lists. 

5) A node becomes disconnected and enters the 
UNATTACHED LISTEN state whenever HELLO -RETRY -MAX hello 
messages are missed from its parent node. 



6) A node enters the ATTACHED LISTEN state 
whenever a single hello message, from its parent, is 
missed. SLEEPING terminals remain awake during the 
ATTACHED LISTEN state. The state ends when the 
terminal receives a data or hello message from its 
parent. The terminal becomes UNATTACHED when a) its 
address appears in the detached list of a hello 
message from an ode other than its parent, or b) 
HELLO-RETRY -MAX hello messages are missed. The total 
number of hello slots spend in the LISTEN state is 
constant • 

If a node in the ATTACHED LISTEN state discovers 
a path to the root which is CHANGE-THRESHOLD shorter, 
it can attach to the shorter path. Periodically, 
SLEEPING terminals must enter the ATTACHED LEARN state 
to discovery any changes (i.e., shorter paths) in the 
network topology. 

Hello synchronization. 

All attached non-terminal nodes broadcast 
periodic "hello" messages in discrete "hello slots- at 
calculated intervals. Base station nodes learn which 
hello slots are busy and refrain from transmitting 
during busy hello slots. 

A terminal refrains from transmitting during the 
hello slot of its parent node and refrains from 
transmitting during message slots reserved in a hello 

message. . 

The hello message contains a "seed" field used in 
a well-known randomization algorithm to determine the 
next hello slot for the transmitting node and the next 
seed. The address of the transmitting node is used as 
a factor in the algorithm to guarantee randomization. 
Nodes can execute the algorithm i times to determine 
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the time (and seed) if the i-the hello message from 

the transmitter. 

After attached, a base station chooses a random 
initial seed and a non-busy hello slot and broadcasts 
a hello message in that slot. The base station 
chooses succeeding hello slots by executing the 
randomization algorithm. If an execution of the 
algorithm chooses a busy slot, the next free slot is 
used and a hello ..displacement" field indicates the 
offset from a calculated slot. Cumulative delays are 
not allowed (i.e., contention delays during the i 
hello transmission do not effect the time of the i+l 

hello transmission) . 

HELLO-TIME and HELLO-SLOT-TIME values are set by 
the root node and flooded throughout the network in 
hello messages. The HELLO-SLOT-TIME value must be 
large enough to minimize hello contention. 

A node initially synchronizes on a hello message 
from its parent. A SLEEPING node can power-down with 
an active timer interrupt to wake it just before the 
next expected hello message. The "^r'TZw 
base station nodes can store messages for SLEEPING 
nodes and transmit them immediately following the 
hello messages. This implementation enables SLEEPING 
terminals to receive unsolicited messages. (Note that 
the network layer always tries to deliver messages 
immediately, before storing them.) Retries for 
pending messages are transmitted in a round-robin 
order when messages are pending for more than one 

destination. v, ollo 
Note that a child node that misses i hello 
can calculate the time of the i+l hello 



messages 
message 



Transport layer theory and implementation notes. 
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The transport layer provides reliable, 
unreliable, and transaction-oriented services. Two 
types of transport connections are defined: 1) a TCP- 
like transport connection may be explicitly requested 
5 for long-lived connections or 2) a VMTP-like 

connection-record may be implicitly set up for 
transient connections. In addition, a connectionless 
service is provided for nodes which support an end-to- 
end transport connection with the host computer. 
10 The interfaces to the next upper (i.e., 

application) layer include: 

CONNECT (access_point, node__name) 
LISTEN (access jpoint) 

UNITDATA (accessjpoint, node_name, buffer, 

15 length) 

SEND (handle, buffer, length) 
RECEIVE (handle, buffer, length) 
CLOSE (handle) 

The "handle" designates the connection type, and 
20 is the connection identifier for TCP-like connections. 

SEND messages require a response from the network 
node (root or terminal) to which the message is 
directed. 

UNITDATA messages do not require a response. 
25 UNITDATA is used to send messages to a host which is 

capable of supporting end-to-end host-to-terminal 
transport connections. 

Because the network layer provides an unreliable 
service, the transport layer is required to detect 
30 duplicate packets and retransmit lost packets. 

Detecting duplicates is facilitated by numbering 
transport packets with unambiguous sequence numbers. 

Transport connections. 
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TCP-like transport connections are used for 
message transmission over long-lived connections. The 
connections may be terminal-to-root or terminal-to- 
terminal (i.e., base stations are not involved in the 

transport connection) . 

TCP-like transport connections are established 
using a 3-way handshake. Each end selects its initial 
sequence number and acknowledges the other end s 
initial sequence number during the handshake. The 
node which initiates the connection must wait a MAX- 
PACKET-LIFE time, before requesting a connection, to 
guarantee that initial sequence numbers are 
unambiguous. Sequence numbers are incremented modulo 
MAX-SEQ, where MAX-SEQ is large enough to insure that 
duplicate sequence numbers do not exist in the 
network. Packet types for establishing and breaking 
connections are defined as in TCP. 

A TCP-like connection is full-duplex and a 
sliding window is used to allow multiple outstanding 
transport packets. An ARQ bit in the transport header 
is used to require an immediate acknowledgment from 

the opposite end. 

VMTP-like connection are used for transient 

messages (i.e. terminal-to-terminal mail messages) . 

VMTP-like connection records are built automatically. 

A VHTP-like connection record is built (or updated) 

whenever a VHTP-lilce transport message is received. 

The advantage is that an explicit connection request 
i. not required. The disadvantage is that longer and 
more carefully selected sequence number, are »^ed^ 
A VMTP-Ii*. connection is half-duplex. (A full-duplex 

. . „<„!,,,.■ laver can be built with two 
connection at a higher layer can 

independent half-duplex VMTP-lilce connections.) 
Acknowledgments must be handled by higher layers. 
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Transport connections are defined by the network 
end-to-end destination and source addresses. 

A MAX_TP_LI FE timeout is associated with 
transport connections. Transport connection records 
are purged after a MAXTP.LIFE time expires without 
activity on the connection. The transport entity in 
a terminal can ensure that its transport connection 
will not be lost by transmitting an empty time-fill 
transport packet whenever TP.TIMEOUT time expires 

without activity. 

The transport entity in a node stores messages 
for possible retransmission. Note that 

retransmissions may not always follow the same path 
(primarily) due to moving terminals and the resulting 
changes in the spanning tree. For example, the 
network entity in a parent node may disconnect a child 
after the DLC entity reports a message delivery 
failure. The child will soon discover that it is 
detached and will reattach to the spanning tree. Now 
when the transport entity (i.e. in the root, re-sends 
the message, it will follow the new path. 

Transport message timing and sleeping terminals. 

The transport entity in a terminal calculates a 
separate timeout for SEND and TRANSACTION operations, 
initially, both timeouts are a function of the 
distance of the terminal from the root node. 

A TCP-like algorithm is used to estimate the 
expected propagation delay for each message type 
Messages, which require a response, are -transmitted 
if twice the expected propagation time expires before 
a response is received. SLEEPING terminals can power 
d own for a large percentage of the expected 
propagation delay before waking up to receive the 



3*8 



- 38 - 



response message. Note that missed messages may be 
stored by the network layer for "count" hello times. 

Medium Access Control (MAC) theory and implementation 

5 notes . 

Access to the network communications channel is 
regulated in several ways: executing the full CSMA 
algorithm (see MAC layer above). The sender 
retransmits unacknowledged messages until a RETRY_MAX 
10 count is exhausted. 

The retry time of the DLC must be relatively 
short so that lost nodes can be detected quickly. 
When the DLC layer reports a failure to deliver a 
message to the network layer, the network layer can 1) 
15 save messages for SLEEPING terminals for later 

attempts, or 2) DETACH the node from the spanning 
tree. Note that most lost nodes are due to moving 
' terminals. 

The node identifier part of the DLC address is 
20 initially all 0's for all nodes except the root node. 

~ The all 0's address is used by a node to send and 

£ received data-link frames until a unique node 

* identifier is passed to the DLC entity in the node. 

| (The unique node identifier is obtained by the network 

25 entity.) 

Address resolution. 

Well-known names too are bound to network 

addresses in several ways: 
3Q _ The network address and TRANSPORT ACCESS 

ID of a name server, contained in the root, is 
well-known by all nodes. 

- A node can register a well-known name 
with the name server contained in the root node. 
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- A node can request the network access 
address of another application from the name 
server by using the well-known name of the 
application. 

Possible extensions. 

Base station-to-base station traffic could also 
be routed through the controller if the backward 
learning algorithm included base station nodes. (Each 
base station would simply have to remember which 
direction on its branch of the spanning tree to send 
data directed toward another base station.) 

The possibility of multiple controllers is kept 
open by including a spanning-tree identifier in 
address fields. Each controller defines a unique 
spanning tree. A node can be in more than one 
spanning tree, with separate network state variables 

defined for each. 

Thus, the preferred embodiment of the present 
invention describes an apparatus and a method of 
efficiently routing data through a network of 
intermediate base stations in a radio data 
communication system. 

in alternate embodiments of the present 
invention, the RF Networks contain multiple gateways. 
By including a system identifier in the address field 
of the nodes, it is possible to determine which nodes 
are connected to which networks. 

Multipath Fading. 

in a preferred embodiment, the data to be sent 
through the RF communication link is segmented into a 
plurality of DATA packets and is then transmitted. 
Upon receipt, the DATA packets are reassembled for use 
or storage. Data segmentation of the RF link provides 
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better communication channel efficiency by reducing 
the amount of data loss in the network. For example, 
because collisions between transmissions on an RF link 
cannot be completely avoided, sending the data in 
small segments results in an overall decrease in data 
loss in the network, i.e., only the small segments 
which collide have to be re-sent. 

Similarly, choosing smaller data packets for 
transmission also reduces the amount of data loss by 
reducing the inherent effects of perturbations and 
fluctuations found in RF communication links. In 
particular, RF signals are inherently subject to what 
is termed "multi-path fading." A signal received by 
a receiver is a composite of all signals that have 
reached that receiver by taking all available paths 
from the transmitter. The received signal is 
therefore often referred to as a. "composite signal" 
which has a power envelope equal to the vector sum of 
the individual components of the multi-path signals 
received. If the signals making up the composite 
signal are of amplitudes that add "out of phase", the 
desired data signal decreases in amplitude. If the 
signal amplitudes are approximately equal, an 
effective null (no detectable signal at the receiver) 
results. This condition is termed "fading". 

Normally changes in the propagation environment 
occur relatively slowly, i.e., over periods of time 
ranging from several tenths (1/10 's) of seconds to 
several seconds. However, in a mobile RF environment, 
receivers (or the corresponding transmitters) often 
travel over some distance in the course of receiving 
a message. Because the signal energy at each receiver 
is determined by the paths that the signal components 
take to reach that receiver, the relative motion 
between the receiver and the transmitter causes the 



receiver to experience rapid fluctuations in signal 
energy* Such rapid fluctuations can cause fading and 
result in the loss of data if the amplitude of the 
received signal falls below the sensitivity of the 
receiver. 

Over small distances, the signal components that 
determine the composite signal are well correlated, 
i.e., there is a small probability that a significant 
change in the signal power envelope will occur over 
the distance. If a transmission of a data packet can 
be initiated and completed before the relative 
movement between the receiver and transmitter exceeds 
the "small distance", data loss to fading is unlikely 
to occur. The maximum "small distance" wherein a high 
degree of correlation exists is referred to hereafter 
as the "correlation distance". 

As expressed in wavelengths of the carrier 
frequency, the correlation distance is one half (1/2) 
of the wavelength, while a more conservative value is 
one quarter (1/4) of the wavelength. Taking this 
correlation distance into consideration, the size of 
the data packet for segmentation purposes can be 
calculated. For example, at 915 MHz (a preferred RF 
transmission frequency) , a quarter wavelength is about 
8.2 centimeters. A mobile radio moving at ten (10) 
miles per hour, or 447 centimeters per second, travels 
the quarter wavelength in about 18.3 milliseconds. In 
such an environment, as long as the segment packet 
size remains under 18.3 milliseconds, fading does not 
pose any problems. In a preferred embodiment, five 
(5) millisecond data packet segments are chosen which 
provides a quasi-static multipath communication 
environment. 
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Duty Cycle. 

In a preferred embodiment , each base station 
broadcasts HELLO messages about every two (2) seconds. 
If upon power up, two base stations choose to 
broadcast at the exact same broadcast, collisions 
between HELLO messages would occur and continue to 
occur in a lock-step fashion upon each broadcast. To 
prevent such an occurrence, each base station chooses 
a pseudo-random offset from the 2 second base time 
between HELLO messages to actually broadcast the HELLO 
message. For example, instead of beginning each HELLO 
message broadcast at exactly 2 seconds after the last, 
the base station might pseudo-randomly offset the 2 
seconds by a negative (-) value of 0.2, yielding a 
broadcast at 1.8 seconds. Because every base station 
generates a different pseudo-random offset generation, 
the problem of lock-stepping collisions is avoided. 

Additionally, instead of using a true 
randomization, a pseudo-random offset is used which 
bases all pseudo-random offset calculations on a seed 
value (the "seed"). The "seed" is broadcast in each 
HELLO message so that the timing of the next HELLO 
message may be calculated by any listening mobile 
terminal. The use of the seed, and pseudo random 
offset generation, allows the terminal to "sleep" 
(enter an energy and CPU saving mode) between HELLO 
messages and be able to "wake up" (dedicate energy and 
CPU concentration on RF reception) and stay awake for 
the minimal time needed to receive the next HELLO 
message. The relationship between the time that a 
base station must remain awake to the time it may 
sleep is called the "duty cycle". 

Using a 2 second HELLO to HELLO message timing 
with a pseudo-random offset range of +/- 1/3 of a 
second, the preferred embodiment has achieved a very 
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low duty cycle. Further details of this timing can be 
found in the Bridge Layer Specification in Appendix E. 

In addition, Appendix A provides a list of the 
program modules which are found in microfiche Appendix 
B. These modules comprise an exemplary computer 
program listing of the source code ("C" programming 
language) used by the network controllers and 
intelligent base transceivers of the present 
invention. ' Note that the term "AMX" found in 
Appendices A and B refers to the operating system 
software used. "AMX" is a multi-tasking operating 
system from KADAK Products, Ltd., Vancouver, B.C., 
Canada. Appendix C, D, E, F, and G provide system 
specifications for the- SST Network Architecture, SST 
Network Frame Format, Bridging Layer, MAC Layer, and 
Physical Layer of one embodiment of the present 
invention. 

As is evident from the description that is 
provided above, the implementation of the present 
invention can vary greatly depending upon the desired 
goal of the user. However, the scope of the present 
invention is intended to cover all variations and 
substitutions which are and which may become apparent 
from the illustrative embodiment of the present 
invention that is provided above, and the scope of the 
invention should be extended to the claimed invention 
and its equivalents. 
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■ 1 iscen-bef ore- calk algorithm: 

lbt.h 
lbt.c 

common routines: 

mac . h 
mac .c 

receive buffers: 

macrxbuf . h 
macrxbuf . c 

-unicast receive routines: 

macrxsm. c 

tranmit buffers: 

mactxptr . h 
mactxptr .c 

unicast transmit state machine: 

mactxsm.c 

unicast transmit and receive sequence control cache 

mcbtbl . h • 
mcbtbl.c 

low-level transmit/recieve files: 

common . h 
rc3250.h 
scc302 .h 
system. h 
vectors .h 
hdlcdriv.h 
internal .h 
io .h 

sstcode . c 
sstphy.c 



Hi 

idge layer iicjinni.-.g^^i riles. 

- address server routines: 

addrsrv.c 
addrsrv.h 

address server task: 

asrvtask.c 

address server task interface: 

asrvtifc.c 
asrvtifc.h 

attached bridge with a zero root priority: 
bb_a . c 

unattached bridge with a zero root priority: 

bb_u . c 
common routines: 

bridge. c 

detached node list: 

detlist.c 
detiist ;h 

pending message container files: 

pendmsg . c 
pendmsg.h 
pmq .c 
pmq .h 

attached bridge with a non-zero root priority: 
r_a .c 

unattached bridge with a non-zero root priority: 
r_u . c 

RARP (reverse address resolution packet) routing table 

rarptbl.c 
rarptbl.h 

packet routing table: 

routetbl . c 
routetbl .h 

bridge function prototypes: 

bridge. pro 
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SST system support routines and header files. 

error codes: 

errcodes . h 
arperr .h 
brgerr .h 
macerr . h 
llcerr . h 
nnmperr .h 

bridge layer system parameters and structures: 

bridge . h 
SST system parameters: 

sstsys .h 

system configuration records (used by the SST task manager) : 

sysctl . h 

generic bubble sort routine: 

bublsort.c 
bublsort .h 

bridge layer transmission queue: 

brgtxq.h 
brgtxq.c 

SST system event and data buffer management functions: 

bufpool.h - header file for all buffer functions. 

bufbrg.c - bridge layer specific buffer functions. 

buf coals. c - buffer coalesce functions. 

bufcopy.c - buffer copy functions. 

buf ere. c - buffer pool create functions. 

bufdisp.c - buffer display function. 

buf enter. c - data entry iterator functions. 

bufevbuf.c - event buffer pointer functions. 

buf hold. c - buffer hold functions. 

bufiter.c - data iterator functions. 

bufllc.c - 11c layer specific functions. 

buf mac. c - mac layer specific functions. 

buf pool. c - buffer pool initialization, post, get and release functions, 

bufpostw.c - buffer post and wait function, 

bufptr.c - event union pointer functions, 

bufrepl.c - buffer replicate functions. 



S3T device idencizier :-r.c: ions 

deviceid . h 
deviceid . c 

generic integer set functions: 

intset . h 
intset . c 

millisecond timer functions: 

mst imer . h 
mst imer . c 

system millisecond timer task 

mtmrtask.c 

network format to integer conversion functions: 

ntoi .h 
ntoi .c 

generic queue/stack/list implementaion: 

qsl .h 
qsl.c 

qsliter.c - queue/ list iterator functions, 
qslpop.c - stack 'pop" function. 

qslret.c - queue re.turn (i.e. to the head of the queue) function. 

SST bridge layer in range node list: 

rangelst . h 
rangelst ,c 

root sequence function: 

rootseq.h 
rootseq. c 

AMX task create functions: 

runproc . h 
runp . c 
runproc . c 

RB4030/RB4020 switch functions: 

sw4030 ,c 

AMX system timer interface functions: 

timer .h 
timer . c 

timer list functions: 

tmrlist ,h 
tmrlist .c 




0 

IV. S3T pre cocci sz.hc k tor a non-Mcrand device (ACS) 

- initialization and event handler: 

ace . h 
ace . c 

- ACE terminal MAC layer functions: 

acemac . c 

- terminal bridge layer address cache: 

adrcache . c 
adrcache.h 

- SST MAC for bus communications to an. ACE entity 

busmac . c 
busmac . h 

- ACE higher layer interface functions: 

llcifc.c 

- example LLC applications: 

listen. c 
send.c 

- dummy LLC layer: 

11c. c 
11c. h 

- LLC layer interface definition: 

llcifc.h 

- RC3250/RB4020/RB4030 task manager: 

sstmgr .c 

- example EE PROM system configuration: 

stbase . c 
st31isw.c 

- terminal bridge layer: 

t_a.c . - attached terminal node. 

t_bridge .c 

t_u.c - unattached terminal node. 

V. Network management protocol modules. 

- nnmp client protocol. 

nnmp . h 
nnmp . c 



induce. 



t_nnmp . h 
nnmpif c . h 
nnmpif c . c 



example client application. 



nnmpapp . c 
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Network Overview. 

The SST system implements a hierarchical radio frequency network of, possibly mobile, terminals used 
nrimariiv for online data entry and occasionally for batch file transfers. The network is characterized by 
sporadic data traffic over multiple-hop data paths consisting of RS485 or ethernet wired links and single- 
channel direct sequenced spread spectrum radio links. The network architecture is complicated by 
moving nodes, hidden nodes, sleeping nodes, transient radio links, and unidirectional radio links. 

The SST network consists of the following types of devices: 

Host - A host computer which communicates with terminals in the SST network. A host can be viewed 
us the network addressable software entity which interfaces the SST network to the physical host 
computer. 

Controller - A eateway which passes messages from a host port to the SST network; and which passes 
messages from me network to a host port. The host port (directly or indirectly) provides a link between 
the controller and a host computer to which terminals are logically attached. Each autonomous network 
must have at least one controller device. 

Base station - An interior node which is used to extend the range of a controller node. Base-station-to- 
controller or base-station- to-base-station links can be wired or radio. 

Terminal - Norand hand-held computer, printer, etc. A terminal can be viewed as the network 
addressable software entity which interfaces the SST network to the physical device. 

The devices are. logically, organized as nodes in an (optimal) spanning tree with a root node in a 
controller device, intend nodes in base stations or controllers on branches of the .tree and terminal nodes 
as (possibly mobile) leaves on the tree. With the exception of the root node, each (child) node i 
mnnected bv a single logical link to a parent node. Like a sink tree, nodes closer to the root ot the 
paSg tree X^dL-nL" from nodes which are further away. Conversely, all nodes are 
••u^ream" from the root Packets are only sent along branches (i.e. logical links) of me spanning tree. 
Nodes in the network use a "backward learning" technique to route packets along branches ot the 
spanning tree. 

Devices in the spanning tree are logically categorized as one of the following three node types: 

Root (or root bridge) - A controller device which functions as the root bridge of me network spanning 
«T L spanning tree has a single root node. Initially, all controllers are root candidates. One. and 
Zy one. rLnode is determined for each autonomous network by using apnonty-based root selecuon 
algorithm. 

Bridge - An internal node in the spanning tree which is used to "bridge" <^^ a ^^^^ 
"nterconnected network. Note that the root node is a bridge and the term "bridge" may be used to re er 
to ™^inal nodes or all non-terminal nodes except the root, depending on the context. A bndge 
node consists of a network Interface point and a routing function. 

Terminal - a leaf node in the spanmng tree. A terminal node can be viewed as the software entity that 
termT^s a branch in the spanning tree. A terminal node consists of a network Interface point and one 
or more terminal access points. 

A controller device contains a terminal node(s) and a bridge node. The bridge node is the root node if 
the controller is functioning as the root bridge. 
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A base sutlon contains a bridge node. A base station does not contain a terminal node. 
A terminal device contains a terminal node. 

Bridging entity refers to a bridge node or to the network Interface point in a terminal device. 

Network interface point refers to the single network addressable entity which must exist in all nodes. A 
network u cerface point is equivalent to the software entity which is used to mtertace the SST network to 

device or bridiini node. Note that a controller device connected to a host computer w.ll have a 
nework £terf Je po.nt which references the host computer and a second discrete network interlace po.nt 
wTcnTe e ences ie bridging node in the controller. Each network mtertace point » .denuf.ed by a 
uZue network address. Unfess otherwise specified, this document uses "network address or supply 
"XssTrefer to the identifier of a network interface po.nt. Note that multiple network mtertace 
points may be referenced with multicast and broadcast addresses. 

Terminal access point refers to a higher layer access point into the network. A terminal access point is 
leftned by the concatenation of the network interface point address and the «nmuri acce* pout 
Sentifier A terminal device or controller device can have multiple termmal access points. 

A loelcal port is defined by a physical port and a network interface point. This implies that a single 
d^vlfe may have more than one physical port with tbe same network address. In tins document port 

refers to a logical port. 
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Fieure 1 I illustrates the relationship between devices, nodes, terminal access points (TAP), network 
Sace pom* (NIP) and network routing tuncuons ( NRF). The controller device has two "e work 
" eSe joints. As an example, the NIP in the controls tenmnal node ,s *T » 
1 mv whSi interfaces to a host computer. The two terminal access po.nts attached to that NIP ulentiry 
Z ^ete .pplSons (i.e. tenmnal emulauon and fde transfer appl.cauons directed to the host computer,. 



controller device 



terminal 
node 




terminal 



terminal 



figure 1.1 



Basic network requirements: 



- Wired or wireless node connections. 

- Network layer transparency. 

- Dvnamic/automatic network routing configuration. 

. legibility. Terminals should be able to move about the radio network without losing a 
data-link connection. 

- Ability to accommodate sleeping terminals. 

- Ability to locate terminals quickly. 

links. 
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Network Layers - Overview. 

The SST network software is functionally layered as follows: 



Medium Access Control (MAC). 
n« MAC , y er ,s res^b ,« to, p,o ; ,*ng J**;— ^ZZ^IZZ^T 

control sublayers, respectively. 

The link control component faolitates reUab.e pouu-to-pomt frame transfers in the absence of collision 
detection and in tbe presence of errors. 

Several channel access control algorithms are used to rebate access to the communicauons channel. 
The algorithms are link-type dependent 

a ~~i«t.„t CSMA/CA (carrier sense multiple access with collision avoidance) protocol is used to 
JSS^SS^TI. column avotdance scheme gtves channel access pnonty to me 

recipient of a unicast frame, 
nodes. 



A polling protocol is used to restrict 
contention for data frames. 



contention to request-for-poU (RFP) frames, thus minimizing 



The channel access control algorithms incorporate a 
instability in contention situations. 



random backoff algorithm to prevent deadlock and 



Bridging Layer. 

The bridging layer has several functions: 

a "wpt I O protocol" to organize nodes in the network into an optimal 

reattached, frequently. 

Tta bridging iayer «~ P**« «« — ? M * tot «°» fc bM< " ""^ "* " 0 '" 
irrninals to annuals along branches of Uk spanning uee. 

HELLO times. 

4) The bndging layer propagates lost node ^formation throughout the spannmg tree. 
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5) The bridging layer maintains the spanning tree links. 

6) The bridging layer distributes network interface addresses. 

7) The bridging layer organizes nodes into logical coverage areas on radio channels. 



Data-link (transport) layer. 

Th, am link hver provides an end-to-end data path between data-link access points in any two nodes in 
2 netork Th Sir* laTer provides a connection-onented reliable service and a connectionless 
the network. The detects and discards duplicate packets and retransmits lost 

^£Zl2l1!£ a datagnun facility for upper layer protocols which provide a 

reliable end-to-end data path. 

a * ten ia^r i cervices for terminal-to-host application sessions which run on 

(ISO layer 4) services for sessions contained within the SST network. 



Higher Layers. 

Ute mmsport prctocol »bicb is u«d for uaDsien. irnenuU ■OTUMMo-cermuul sess»ns. 



Dt 



Network address requirements. 

MAC frames contain a hop destination and hop source address in the MAC header. 
Bridging packets contain an end-«D-end destination and source address in the bridging header. 

MAC and bridging addresses are consistent and have the same format- 

Montirw which is oroerammed into the device at the factor- 
All devices must have either a unique ^^^^SSS^ long address/alias binds b . 
and/or an alias which is typically entered by the user or is well toowiu s 
short network address, obtained from an address server in the root node. A netwonc 
identifies the network Interface point in each node. 
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The network Interface point, in each node, obtains a network address from an address server ... the 
^ol whTcb umquely identifies the node. The network interface point passes the rework address to the 
MAC "entity attached to each port on a device. Short addresses are used to minunue packet >,ze>. 

Network addresses consist of 2 pans: 

- a node type. Node types are well-known. Some node types are used for multicast messages . i.e. all 
bridges). 

- ;i unique, multicast, or broadcast node Identifier. 

A node-type identifier of all l's is used to specify all node types. 
The node identifier part of a root address is all O's. 

A node identifier of all I s is used to specify any node of the specified type, and is the default node 
identifier, used before a unique node identifier is obtained. 

In addition, to source and destination addresses, each network packet contains a spanning tree Identifier 
in the MAC header. 

A default spanning tree identifier is well-known by all nodes. 

which other nodes can attach must be entered into each node. 
Network address allocation. 

returned to the requesting node in a RARP.response packet, 
packet to the root.) 

£ by a revesting node if i< bas neve, been used or if i. bas been .nacuve for a MAX.ADDRESS.L1FE 

time period. 

to zero and returns the old address. 
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Bridging layer theory and implementation notes. 

The bridling layer organizes nodes inn an opumal spanmng tree with a single root bridge at the root of 
Te cree Note U,at the spanning tree .denuf.er allows more than one log.cal tree to ex.su ^ *™ 
.overaee area.) Spanning tree organizauon is faceted wid. a HELLO protocol wh.ch seleos a ^root 
node uS bibles nodes to determine the shortest path to the root before attaching to the spanmng tree. 
^ m ^7!Te Led along branches of the spanning tree. Restricting each node to a s.ngle parent 
guarantees that there will be no loops in the logical topology. 
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Rsures 2 I and 2.2 illustrate how physical devices are organized into logical nodes in a spanning tree. 
Figure 1 1 depicts devices and the physical conjunction links. Figure 2 2 depicts the ^devices 
oSSzed as nodes on branches of a spanning tree. The root node in tig. 2.2 is labeled w.th an R. 



SNA host 



TCP host 



controller 



controller 




| terminal 
O base station 



figure 2.1 
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SNA host 




TCP host 

1 1 






I terminal node 
O bridge node 



Figure 2.2 



Spanning tree organization. 

Nodes in the network are generally categorized as ATTACHED or UNATTACHED. Initially, only the 
ro*°s "tached A single controller may be designated as the root, or muluple root candidates (i.e. 
controllers) may negotiate to determine which node is the root 

Attached bridge nodes and root candidates transmit HELLO.response packets at calculated intervals. The 
HELLO.response packets include: 

- the source address. 

• a broadcast destination address. 

- the distance (cost) to the root. 

The incremental oomon of the distance between a node and its parent is primarily a function of the 
SsS irSpeTe e* met. RS485. or radio). On radio links, bridging connections m biased toward 
^w^dTbest ignal strength. Signal strength is not a factor in the cumulative path distance. The 
t^^S^^S^A to'bias pSh selection toward high-speed (i.e. wired) connection, 

- a "seed" value used to calculate the time of the next HELLCresponse packet. 

- a hello slot displacement The displacement specifies the displacement of the actual hello slot time 
from the emulated hello slot time or to mdicate that the hello time was not calculated (,.e. was 
unscheduled). 
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- a spanning tree identifier (LAN ID). 

- the priority of the root node (or root candidate). 

- die long, unique device identifier of the root node (or root candidate). 

- a mot node sequence number, used to distinguish between multiple occurrences of the spanning tree 
with the same root node. 

Attached nodes must forget their network address and return to the UNATTACHED suite whenever a 
HELLO-response packet is received with a new root node .denut.er or sequence number. 

Optional parameters: 

- descendent count. 

- a pending message list 

Pending message lists consist of 0 or more network addresses for SLEEPING terminals. Pending 
messages for terminals are stored in the parent node. 

- a detached-node list- 

internal nodes when a child is lost. Entries are included in HELLO response packets 
DETACH.MSG.LIFE hello times. 

HELLO.response packets and do not affect regular hello timing. 

distance to the total distance of its new parent, and begins to transmit HELLO Jesponse paoceis 
The end-t<~nd ATTACH.request functions as a discovery pack.., and enables nodes in the path 
the root node to quickly learn the address of the source node. 

the listening node waits (i.e. sleeps) and retries later. 
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An attached node may respond to a HELLO.response packet from a node other than its parent « i.e. with 
m ATTACH request packet) if the difference in the bop count specified in the HELLO.response packet 
exceeds a CHANGE.THRESHOLD level. 

Unattached nodes may broadcast a global HELLO.request with a multicast bridge desunauon address_w 
solicit short HELLO.response packets from attached bridges. The net etfect ,s that the UNATTACHED 
suite mav (optionally) be shortened. ( Note that only attached bridges or the root may respond to tin 
ATTACH.request packet.) Normally, this facility is reserved for terminals with transactions in progress. 

ATTACH.request packets may contain a descendants list, so that an internal node may attach itself and 
the subtree under it to a bridge node closer to the root. 

ATTACH.request packets contain a "delivery service type" field, which indicates that a tennmal ( i.e. 
which sent the request) may be SLEEPING, and a "maximum stored message count field The bndg ng 
entTrv ,n 1 parem of a SLEEPING tennmal will temporarily store messages, for later delivery . .f that 
service is requested. The bridging entity in a parent node will store pending messages unul 1) the 
message is delivered, or 2) "maximum stored message count" hello times have expired. 

Data-link layer data can be piggybacked on an ATTACH.request packet from a terminal. 
Attachment criteria. 

On wired links, the weighted distance is the only criteria for choosing a parent. 
On radio links, a parent is chosen based on the following criteria: 

l > The sienal strength must exceed a minimum threshold value. . ... . . , . „ ; 

ii ^two polenSl parent nodes are at a different distance from the root, the one with the least distance ,s 

3Hf e two potential parent nodes are at the same distance, the node with the best signal strength* choser. 
4) If two ££L parent nodes are at the same distance and have the same signal strength, then the node 

£ SST- - ^ *<* - node wi * - highesl long ID or ls 

chosen. 

The intent of the above criteria is to create stable disjoint logical coverage areas in the presence of 
^rove^pmg coverage areas. Ideally, all radio terminals in acoverage area will be attached to 
a single bridge node. 

The concept of logical coverage areas is illustrated in the figure below. 



figure 3.1 
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Three radio bridge nodes. Bl. B2. and B3. with network addresses of 1. 2. and 3 are depicted in hgure 
1 1 All three nodes are assumed to be at the same distance from the root. The circles around each node 
denote physical coverage areas. The dark shaded areas denote strong signal coverage areas. The logical 
coverage of Bl is depicted bv its dark and light shaded areas. The logical coverage areas ot Bl and B3 
■ve depicted by the associated dark shaded and non-shaded areas. Note that the dark shaded area ot B 1 
would logically hide the dark shaded area of B2 or B3 if the areas physically overlapped. Also note that 
the loviicfil covera2e area of a fourth bridge with the same distance and a higher address, say B4. could be 
completely hidden behind one of the three bridge nodes, if B4 and one of the other bridges were located 
Mde-by-side. 

The concept of disjoint logical coverage areas is especially important when radio bridge nodes are placed 
in close proximity to provide redundant coverage (i.e. for protection against a failure). The MAC entity 
in one of the bndge nodes can efficiendy regulate access to the channel (i.e. by queuing terminals tor 
polling) without coordination with other co-located bridge nodes. 



Bridging layer routing. 

All packets are routed along branches of the spanning tree. Bridges "learn" the address of finals by 
monitoring traffic from terminals (i.e. to the root). When a bridge receives a packet directed toward the 
Zt (i e. moving downstream), the bridge creates or updates an entry in its routing table for the terminal. 
The entry includes the terminal address, and the address of the bridge which sent me packet (i.e. me hop 
source address). When a bridge receives an upstream packet (i.e. moving from the root, destined for a 
terminal) the packet is forwarded to the upstream node which is specified in the rouung entry for the 
destination. Upstream packets are discarded whenever a routing entry does not exist Downstream 
packets (ie. from a terminal to the root) are simply forwarded to the next downstream node (i.e.the 
parent) n me branch of the spanning tree. No expUcit routing Is required for *»^» «^«' nce 
me route is defined by the structure of the spanning tree. A packet travels downstream unul a node is 
reached which has an entry in its routing table for the destination address. The packet is Aeoexphcdy 
routed upstream unul it reaches its destination. Thus, terminal.to-term.nal communications Is 
accomplished by routing all traffic through the nearest common ancestor of both terminals. In the 
worst case, the root is me nearest common ancestor. An address resolution server » the root node 
facilitates terminal-to-terminal communications (see below). 
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For example, in figure 3.1, if terminal E sends a packet to terminal B. the packet w,U follow downstream 
hops from E to 3. 3 to 2. 2 to 1. and 1 to R. where R is me root node. Routing tables are not required tor 
S\e downstream hops. The routing function at R has an entry for B in its routing table when specit.es B 
as the first upstream hop to B. Therefore the packet is explicidy routed upstream from R to B. 

As a second example, if terminal D sends a packet to terminal E. the packet will follow one downstream 
hop from D to 2. The rouung function at 2 has an entry for E in its routing table which specihe, 3 as the 
Eft upsueam hop to E. The packet is routed upstream to 3. An entry ,n the rouung table at 3 spect.es E 
as the first upstream hop to E. and the packet is routed from 3 to E. 




| terminal node 
O bridge node 



figure 3.4 



As in extension to the routing algorithm described above, terminals may optionally cache ^dresses 
c . "rr 10 H ir«-t route table If a terminal has a message for a desunauon listed m its 

Sh of^elpa^guee. Direct route table entries must be aged relanvely quickly. ^ ^ect 
^l^ton fSTSe entry in the direct route table is discarded and the packet is simply forwarded 
^^^S^iaL format field in the bridge header must be set to point-to-potat for 
dSy u^srni^T^ets. Direct routing has obvious advantages; however it forces terminals to 
maintain additional MAC layer state informauon. 

As an example of direct routing, in figure 3.4. terminal E can route packets direcdy to F, if E has an entry 
for F in its direct routing table. 

Liver. 
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Dynamic Changes in the Spanning Tree. 

Paths in the spanning tree can change for a number of reasons: 

1) Any node may select a new path to the root whenever a better path is found. For example, a better 
path might be one where the distance of a node's parent from the root is CHANGE_THRESHOLD 
greater than the distance in a HELLO.response packet from another node. Note that 
CHANGE.THRESHOLD can be as small as 1. All else being equal, a node on a radio channel should 
always choose, as its parent, the node with the best signal strength. A node can move its entire subtree by 
including a decedents list in the ATTACH.request packet sent to the new parent. Rapidly moving 
terminals can cache a short list of alternate parents. Periodically, SLEEPING terminals, must stay aw;ike 
for 1+ HELLO times to discover changes (i.e. shorter paths) in the network topology. 

2) A parent node detaches the subtree rooted at a child node, whenever a message cannot be delivered to 
the child. This occurs when the MAC layer in a parent node fails to deliver a unicast bridging layer 
packet to a child node. In addition, the bridging entity in a parent node can retain messages for a child 
terminal node. Terminals request the saved messages by sending a request packet to the parent with an 
"awake time" parameter. If the message is not requested and delivered after 'store message count" 
hello times, then the terminal is detached. If the detached node is a bridge node, the parent node will 
send a DETACRrequest packet, to the root node, which contains a decedents list that defines the lost 
subtree. If the detached child is a terminal, the parent will flood a DETACH.request throughout all 
branches of the spanning tree using a reliable flooding mechanism. 

The detached node information which is broadcast in flooded DETACH^equest packets is added to the 
"detached node set" maintained in each bridge node. The detached node set is copied into the detached 
node list in the bridge's HELLO.response packets. The entries in the detached node list are discarded 
alter MAX_HELLO_LOST+ 1 HELLO times. 

3) A child node goes into the UNATTACHED state whenever its MAC layer fails to deliver a message to 
its parent. If the child node is a bridge, it must continue to broadcast scheduled HELLO.response packets 
with an infinite distance for MAX_HELLO_LOST+l times. If the child node is a terminal, it may 
solicit short HELLO.response packets to shorten the UNATTACHED state. After the UNATTACHED 
learning state has expired the node reattaches by transmitting an ATTACH.request to the bridge node 
closest to the root 

4) If a node in an ATTACHED state receives a DETACH packet or a HELLO.response packet with its 
network address in the detached list, it must enter the UNATTACHED state and reattach to the spanning 
tree. Note that it may not actually be unattached. The node can shorten the UNATTACHED state by 
soliciting short HELLO.response packets. After reattaching, the node must remain in a HOLD. DO WN 
state for MAX_HELLO_LOST+l hello times. During the HOLD.DOWN state, the node ignores its 
address in DETACH packet and HELLO.response packet detached lists. After the HOLDJDOWN period 
expires the node must send a second ATTACRrequest to the root to insure that it is still attached. 

5) Entries in routing tables are aged. When routing table space for a new entry is required, either an 
unused entry or the oldest (i.e. least recently used) entry is selected. If a used entry is selected, then the 
old information is simply discarded. The aging factor associated with each table entry is reset to 0 each 
time a new packet from the associated node arrives. A node must periodically send an ATTACH.request 
packet to the root node to maintain its path in the spanning tree. The ATTACH.request can be 
piggybacked on a higher-layer data packet if the node is busy. If the root node is on the path to the 
destination of the data packet then the overhead required to keep the node's address alive is minimal. 
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6) A SLEEPING node must wake up and enter an ATTACHED listen state whenever a threshold number 
( i.e. 1 or 2) of HELLO^esponse packets, from its parent are missed. The stateends when the node 
receives a data or HELLO.response packet from its parent. The node enters the UNATTACHED state 
when a) its address appears in the detached list of a DETACH or HELLO.response packet, or b) a total 
or MAX_HELLO_LOST consecutive HELLO.response packets are missed. 

The time that a node spends in the ATTACHED LISTEN state must he less than the lifetime of 
detached node information in the network. This insures that a detached node will always enter the 
UNATTACHED suite (i.e. either the node will find its address in a detached node list or the node will 
miss MAX_HELLO_LOST HELLO.response packets and go into the UNATTACHED state before it 
sees a "good" HELLO.response packet from its (former) parent. 

7) Any node which receives a HELLO.response packet from its parent with an infinite distance 
immediately enters the UNATTACHED state. If the node is a bridge, it must continue to broadcast 
HELLO.response packets with an infinite distance for M AX_HELLO_LOST+ 1 times. 

Note that old invalid paths may exist in the spanning tree for a period of time. For example, if a terminal 
detaches and reattaches to a different branch in the spanning tree, all downstream nodes in the new 
branch (quickly) "learn" the new path to the terminal. Nodes which were also in the old path change 
their routing tables and no longer forward packets along the old path. At least one node, the root must 
be in both the old and new path. A new path is established as soon as an end-to-end attach request 
packet from the terminal reaches a node which was also in the old path. Any remaining old path 
fragment will be disjoint from the new path. 



Detach Packet Logic. 

A parent node generates a DETACRrequest packet whenever it is unable to deliver a message to a child 
node. The two possible cases are 1) the child is a bridge, and 2) the child is a terminal. 

Case 1 - The lost node is a bridge. 

When a parent node is unable to deliver a message to a child bridge node, it must send a 
DETACRrequest packet, to the root node, which contains a detached node list that describes the lost 
subtree. The list will contain all nodes in the routing table of the parent for which the lost bridge was the 
first upstream hop. All downstream nodes in the path of the DETACH packet must adjust their routing 
tables by deleting entries which match those in the detached list 

Case 2 - The lost node is a terminal. 

Since terminals can be mobile they can be lost often and must be notified quickly. When a parent node is 
unable to deliver a message to a terminal, it must generate a DETACRrequest packet, with the terminal 
specified in the associated detached node list, and flood the packet throughout ail branches of the 
spanning tree. The packet is forwarded using a reliable broadcast mechanism. The DETACH packet 
contains a forward list which is used to specify which nodes should forward and acknowledge the 
DETACRrequest Initially, the forward list consists of all bridges which are either children or the parcm 
of the node which generated the packet Nodes in the forward list acknowledge the DETACRrequeM. 
with a DETACRresponse, and forward the DETACH^equest along all branches of the spanning tree 
except the branch it was received on, with one exception. A bridge node in the forward List does not 
forward an entry in the detached list of a DETACH.request if 1) the DETACHj-equest came from an 
upstream node, and 2) the upstream node is not the first hop in the routing table entry associated with the 
entry in the detached list Upstream bridges, which do not have bridge nodes as children, broadcast the 
DETACH.request one time (without a forward list). 
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Note that the destination address used to forward a tlooded DETACH.request is global. Therefore, the 
detached terminal may receive a DETACH.request and quickly learn that it has been detached. All 
bndge nodes, which receive the DETACH.requesL add the detached terminal to their detached node list 
which is broadcast in HELLO.response packets for MAX_HELLO_LOST+l times or until the bridge 
determines the terminal has reattached. 



Hello synchronization. 

All attached non-terminal nodes broadcast periodic HELLO.response packets at calculated intervals. On 
the average, the intervals are separated by HELLO.PERIOD seconds. The HELLCresponse packet 
contains a "seed" field used in a well-known randomization algorithm to determine the next hello time 
for the transmitting node and the next seed. The address of the transmitting node is used as a factor in the 
algorithm to guarantee randomization. Nodes can execute the algorithm i times to determine the time 
(and seed) of the i-ih hello packet from the transmitter. 

After attaching, a bridge chooses a random initial seed and a "hello slot" and broadcasts a hello packet in 
that slot. The bridge chooses succeeding hello slots by executing the randomization algorithm. If the 
transmission of a HELLO response packet is delayed, then the delay is entered into a hello 
"displacement" field in the packet, so that the calculated time can be accurately derived by a receiver. 
Cumulative delays are not allowed (i.e. contention delays during the i-th hello transmission do not effect 
the time of the i+1 hello transmission). 

A node initially synchronizes on a HELLO .response packet from its parent A SLEEPING node can 
calculate the time of the next expected HELLO.response packet from its parent and can power-down with 
an active timer interrupt set to wake it just before the HELLO.response packet is transmitted. The 
bridging entity in a parent node can store a message for a SLEEPING node until the SLEEPING node 
"requests" the message by notifying its parent that it is awake. A terminal learns that it must request 
unsolicited saved message by examining the pending message list in the HELLO.response packet This 
implementation enables SLEEPING terminals to receive unsolicited messages and relaxes the timing 
constraints for transaction oriented messages. Retries for pending messages are transmitted in a round- 
robin order when messages are pending for more than one destination. 

Note that a child node, which misses i HELLO.response packets, is able to calculate the time of the i+ 1 
HELLO.response packet 



Data-link/Transport layer theory and implementation notes. 

The data-link layer is implemented as an extension of Class 2 Logical Link Control (LLC) as defined in 
ISO Standard 8802-2.2. The extensions to LLC are 1 ) an additional unnumbered command frame - 
SABMX, and 2) 15-bit send and receive sequence numbers. In addition, the implementation must 
include an adaptive time-out algorithm for retransmissions. Unreliable (type 1) and reliable (type 2) 
connection-oriented services are provided. The unreliable service is provided for terminals which 
support a reliable end-to-end transport protocol with a host computer. LLC type 2 provides a reliable 
end-to-end transport service for long-lived terminal-to- terminal connections within the spanning tree 
network. 

In addition, a fast-connect VMTP-like transport protocol, is used for transient terminal-to-terminal 
connections. The VMTP-like service is primarily provided for remote procedure calls (RPC), 
client/server transactions, and short mail messages. 
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Note that the bridging layer does not provide a reliable end-to-end service and that lost and duplicate 
packets must be handled by a higher layer. The bridging layer does not fragment packets and packets ;ire 
normally delivered in sequence. 

The interfaces to the next upper (i.e. application) layer include: 

handIeaCONNECT(destination ) 

h;uidle=LISTEN(SSAP, . . .) 

SEND(handIe, buffer, length, [destination]) 

DATAGRAM(faandie, buffer, length, [destination]); 

TRANSACTION(handle, tx _buf, tx Jen, nc.buf, max.ncjen, 
IDEMPOTENT, destination) 

RECEIVE(handle, buffer, maxjength, [destination]) 

PENDING_MESSAGE(bandle, [destination]) 

DISCONNECT(handle) 

Destination fields are formed by concatenating the destination service access point (DSAP) with the 
destination network address, where aliases are used for both . For example, 3270 @ HOST 1 might 
designate a 3270 terminal controller application in a controller node. The DSAPs for common 
applications are well-known. Note that the DSAP can specify a remote terminal application or the access 
point to a higher layer protocol in a remote node. 

The "handle" designates the connection type, and is the connection identifier for LLC connections. 
The optional "destination" field in send and receive operations is only used for the VMTP-like interface. 
SEND messages require a response. 

DATAGRAM messages do not require a response. DATAGRAM is used to send messages to a host 
which is capable of supporting end-to-end host-to-tenninai transport connections. 

TRANSACTION is used to send transaction-oriented messages with the VMTP-like facility. An error 
occurs if a return message is not received in a TRXN_TIME-OUT period. The data- link/transport entity 
saves response messages and resends the response when a duplicate transaction message is received. In 
addition, an application can mark a transaction as redoable, by setting the IDEMPOTENT flag ON. In 
this case, the response message is not saved and the response is regenerated by re-executing the 
transaction. Note that a response message can be guaranteed in the form of an acknowledgment from a 
higher layer protocol. 

Because the bridging layer provides an unreliable service, the data-link layer is required to detect 
duplicate packets and retransmit lost packets. Detecting duplicates is facilitated by numbering data-link 
packets with unambiguous sequence numbers. 
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Data-link connections. 

LLC type 2 connections are established by sending a SABMX control frame to the destination network 
address. To prevent frames from an old connection from being accepted (i.e. with a sequence number of 
0) the node which initiates a connection must insure that at least MAX_PACKET_LIFE time has expired 
since the last connection before issuing a new CONNECT for the same destination. Because of the 
required waiting period. Type 2 LLC connections are not ideal for the type of transient "connections" 
needed to reliabiy facilitate remote procedure calls, client/server transactions, and sporadic mail 
messages. 

LLC frames are sequenced from 0 to MAX.SEQ. The maximum number of outstanding frames (i.e. 
transmitted, but not acknowledged) is LLC_WINDOW_SIZE. The default value of 
LLC_WINDOW_SIZE is relatively small but the window size may be expanded with an XID frame. 
Since all frames sent during a connection may not follow the same path, no more than MAX.SEQ frames 
may be sent in a MAX_PACKET_LIFE time period. A problem can arise when a node successfully 
transmits a data-link frame to the next downstream hop on a busy path, but loses ail acknowledgments. 
At this point, the node is detached and must quickly reattach to the spanning tree. If the next parent of 
the node is on a shorter, less busy branch, frames on the new path can easily arrive at the destination 
while old frames still exist in the old path. MAX_PACKET_LIFE is equal to (MAX.HOPS • 
XMIT_Q_SIZE • MAX_RETRY_TIME), where MAX JiOPS is the maximum length of a branch of the 
spanning tree, in hops, XMIT_Q_SIZE is the number of packets which can be queued in each node, and 
MAX _RETRY_TIME is the maximum time the MAC layer can spend retrying a frame before it is 
successfully sent. This problem was addressed by increasing the size of the send and receive sequence 
number fields (i.e. from 7 bits to 1 5 bits) so that the N(S) and N(R) fields in an information frame can 
never roll over faster than MAX_PACKET_LOFE time. Note that the spanning tree topology insures that 
packets will not loop.. . 

VMTP-like connection records are built automatically. A VMTP-like connection record is built (or 
updated) whenever a VMTP-like transport message is received. The advantage is that an explicit 
connection request is not required. A VMTP-like connection is half -duplex. (A full-duplex connection 
at a higher layer can be built with two independent half-duplex VMTP-like connections.) 
Acknowledgments must be handled by higher layers. 

Connections are defined by the concatenated network end-to-end destination and source addresses, and 
destination and source service access points. 

The LLC type 2 data-link entity in a node stores messages for possible retransmission. Note that 
retransmissions may not always follow the same path (primarily) due to moving terminals and the 
resulting changes in the spanning tree. For example, the bridging entity in a parent node may disconnect 
a child after the MAC entity reports a message delivery failure. The child will soon discover that it is 
detached and will reattach to the spanning tree. Now when the data-link entity (i.e. in the root) resends 
the message, it will follow the new path. 



Data-link message timing and sleeping terminals. 

The data-link entity in a terminal calculates a separate time-out for SEND and TRANSACTION 
operations. Initially, both time-outs are a function of the distance of the terminal from the root node. 

A TCP-like algorithm is used to adjust the expected propagation delay for each message type to the end- 
to-end distance and load, without causing sporadic changes or dramatic swings in time-out values. 
Messages, which require a response, are retransmitted if twice the expected propagation time expires 



NORAND CONFIDENTIAL 



is 



Norand SST Network 
SST Network Architects *re 



Revision I, 7/31/92 



PA(iE 21 



before a response is received. SLEEPING terminals can power down for a large percentage of the 
expected propagation delay before waking up to receive the response message.' Note that missed 
messages may be stored by the bridging entity in a parent node for "store message count" hello times. 

The LLC entity at each end of a connection should be notified when a bridging layer path change has 
occurred. The notification will trigger ;in RR or data LLC message transmission if unacknowledged 
messages exist on the connection, or an expected reply has not been received. 



Medium Access Control (MAC) theory and implementation notes. 

The MAC layer is responsible for providing reliable transmission between any two nodes in the network 
(i.e. terminal-to-bridge). 

Access to the network communications channel is regulated in several ways: 

- Nodes are grouped into logical coverage areas associated with a single bridge node. 
• CSMA and LBT algorithms are used to gain access to the channel. 

- A polling protocol reduces contention for data frames. 

IEEE 802.3 media access control is used for ethernet links. 

A p-persistent CSMA/CA with ARQ (automatic retry request) protocol is used to gain access to the 
channel on the RS485 LAN. 

A collision avoidance protocol is implemented on RS485 LAN links. Bridging layer packets are 
typically sent in a single MAC layer data frame on both ethernet and RS485 LAN links. Short blocks can 
be transmitted as soon as an idle channel is detected. Before a long data frame can be transmitted on a 
wired link a potential transmitter must sense an idle channel, transmit an RFP frame and receive a POLL 
frame from the receiver. After a data frame is transmitted the receiver notifies all listening nodes that 
the channel is free by sending a CLEAR frame. 

A simple return priority mechanism is implemented by requiring a potential transmitter to sense an idle 
line for an IDLE_TIME period which exceeds the maximum transmitter/receiver turnaround time. The 
recipient of a unicast frame "owns" the channel for the turnaround time and can respond without 
executing the CSMA algorithm. This approach makes response times more deterministic and allows the 
sender to set response time-outs tightly. Short time-outs allow transmitting nodes to quickly retry out and 
discover disconnected links. 

A CSMA random backoff algorithm specifies backoff delays as a function of the CSMA slot time. A 
CSMA slot is calculated as a function of the worst-case carrier sense ambiguous period. If, for example, 
in the worst case, it takes a character-time to determine that a frame is in progress then the CSMA slot 
time is defined to be slighdy longer than one character time. The algorithm divides the sense time into p 
contiguous slots and chooses a number i, between 1 and p. If the first i slots are idle then the algorithm 
allows transmission in the i+ 1 slot If one of the first i slots is busy, then the device executing the 
algorithm listens until the channel is idle and re-executes the algorithm. 

A polling protocol, which is consistent with the collision avoidance protocol used on wired links, is 
used to gain access to the channel on spread spectrum radio links. The polling protocol reduces 
contention, in an environment with hidden terminals, in several ways. 

On radio links, a MAC transmitter fragments a bridging layer packet into short fixed length frames before 
the packet is sent. The fragments are reassembled by the receiver and are posted to the receiver's 
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bridging layer if, and only if, all frames in the packet are received. A group of frames which is 
associated with a single bridging layer packet is called a bracket. Fragmentation at the MAC layer 
;illows the MAC entity to used a (shorter) frame size which is suitable for the link error rate without 
impacting packet sizes at the bridge layer. 

< )n radio links, the polling protocol generally limits contention to RFP frames. Before a bracket ot 
frames can be transmitted on a radio link, a potential transmitter must sense an idle channel, transmit ;w 
RFP frame and receive a POLL frame from the receiver. If the receiver is busy it will respond with a 
wait-for-poll (WFP) frame. The WFP frame positively acknowledges the RFP frame and causes the 
transmitter to wait for a POLL frame. Nodes are queued for polling in the order in which RFP frames 
arrive. After the last frame in a bracket is transmitted and successfully received, the receiver sends a 
CLEAR frame to notify all listening nodes. Since coverage areas tend to be logically disjoint a single 
bridge can generally determine access to the channel, within its coverage area, for the transmission of all 
frames except for RFP (and ENQ) frames directed to the bridge. 

The MAC entity attached to a radio port must monitor traffic volume on the port. Under lighdy loaded 
conditions a non-persistent CSMA/CA with ARQ algorithm is used to gain access to the channel. A 
node simply listens and transmits an RFP (request-for-poil) frame immediately if the channel is sensed to 
be idle. If the channel is busy, the node defers until later. 

Under moderate to heavy load conditions, the polling protocol incorporates a p-persistent LBT/BP with 
ARQ algorithm to regulate access to the channel. As Kleinrock and Tobagi noted in [1], the throughput 
performance of a packet radio network can be significantly degraded by as few as 5 to 10 per cent hidden 
nodes. In [3] Tobagi discussed the use of a busy tone on a separate frequency. The disadvantage of the 
busy tone solution is that it requires two transmitters and receivers per node. The LBT/BP protocol 
provides a somewhat equivalent solution with the use of a single frequency. After the first RFP frame, all 
other frames sent in a sequence of frames associated with a single bracket are sent without sensing the 
channel. Because of this return priority mechanism and because the MAC entity fragments packets 
into frames of a fixed size (or smaller) the time between POLL frames (and DATA frames) Is fixed. The 
POLL (or DATA) frames in a bracket provide a busy pulse which notifies other nodes in the coverage 
area of either the transmitter or receiver that a conversation is in progress. All nodes are required to 
sense an idle channel for a time which exceeds the tnterpoil gap time before transmitting an RFP frame. 
The LBT/BP protocol insures that an active conversation will be detected if either the active transmitter 
or receiver are in range (but not necessarily both). Figure 4. 1 below further illustrates this point. 



The example in figure 4.1 depicts a three nodes, A, B, and C, with physical radio coverage areas 
represented by the circle around each node. Note that B is in the coverage area of both A and C, A ism 
the coverage area of B but not in the coverage area of C, and C is in the coverage area of B but not in the 
coverage area of A. Assume that B is polling A to solicit data frames when C first attempts to acquire ilk- 
channel. Since the LBT algorithm requires C to detect an idle channel for a time which exceeds the 




figure 4.1 
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interpoll gap time, C will detect a poll frame from A and will defer from transmitting until the 
conversation is finished. 

An LBT random backoff algorithm for radio links specifies backoff delays as a function of the CSMA 
slot time and the LBT slot time. An LBT slot is defined as a function of the worst case busy-sense time. 
In figure 4.1, suppose nodes A and C attempt to initiate a conversion with B at approximately the same 
time. If A determines that the channel is idle and begins transmitting an RFP frame at time 0. then the 
worst c;ise busy-sense time is equal to the time, u at which C begins sending a poll frame. 

The backoff algorithm is executed, whenever a collision is suspected, to randomly distribute retries over 
an increasing number of LBT slots. The channel access algorithm used on radio channels treats "busy 
sense 1 ' as a collision and assumes that a collision may have occurred whenever a response is missed, since 
collision detection is not available. , 

The bridge layer is responsible for indicating to the MAC layer that a packet is being sent as a response 
to a multicast or broadcast message. If a packet is being sent in response to a multicast message, then 
the MAC layer waits for a random delay period before transmitting the response. 

Broadcast and multicast frames are never retransmitted at the MAC layer. 

The retry time of the MAC must be relatively short so that lost bodes can be detected quickly. When the 
MAC layer reports a failure to deliver a message to the bridging layer, the bridging layer can 1) save 
messages for SLEEPING terminals for later attempts, or 2) DETACH the node from the spanning tree. 

The node identifier pan of the MAC address is initially all l*s for all nodes except the root node. The all 
I s broadcast address is used to by a node to send and receive address resolution packets, which are used 
to obtain a network address. 



Address resolution. 



Reverse Address Resolution Protocol (RARP) protocol overview. 

A node which does not yet have a 16-bit network address must request a network address from a RARP 
server in the root node. The node uses an 1 1-bit node ID of all Ts until a unique ID is assigned by the 
RARP server. A RARP request packet containing the requesting node's unique 48-bit long ID and/or an 
alias (i.e. LPT1) for the 48-bit identifier, is sent to the server by the requesting node. The RARP server 
routes a R ARP^es ponse packet back to the requesting node using temporary RARP routing tables. A 
table entry is created in each node on the path to the root when the request is sent. When the 
RARP.response packet returns upstream, each node records the network address assigned to the 
requesting node. On the last hop, the RARP.response packet is broadcast to the requesting node. If the 
packet is not delivered successfully, a retry is initiated by the bridging entity in the requesting node alter 
a BRIDGEjnMEOUT period expires. The parent of the requesting node can service the retry without 
forwarding the retry RARP^equest to the root In general, if a bridge node receives a RARP request and 
the long identifiers in the request matches an entry in its RARP routing table, and that entry has a valid 
16-bit network address, then the bridge node can simply return a RARPjesponse, with the 16-bit address, 
without forwarding the request to the root node. Note that RARP routing table entries are aged and 
discarded before the address can become invalid. 

A requesting node can specify that it does not have a 48-bit ID by not including it as a parameter or by 
including an ID of all 0's. An alias is required if there is no 48-bit ID. 
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A requesting node can specify that it does not have an alias by not including it as a parameter, or by 
including an alias with a length of 0. 



The long identifiers in a RARP.request match temporary entries in a RARP routing table I) if matching 
48-bit IDs and aliases are present in both, 2) if both contain a matching alias and neither has a 48-bit ID , 
or 3 ) if both contain a matching 48-bit ID and neither has an alias. 

Note that the RARP request function serves two purposes: 1) A 16-bit network address is obtained, and 2) 
The long ID and/or alias of the requesting node are registered with the address server. 



Address Resolution Protocol (ARP) protocol overview. 

A node can request the 16-bit network address of another node by sending an ARP.request packet to an 
ARP server in the root node. The ARP.request packet must contain either the 48-bit identifier or the alias 
of the target node. The ARP server returns the 16-bit network address of the target node in an 
ARP.response packet 



Network Management 

An SNMP-like network management provided is provided through a dedicated network control point 
which exists in a controller device. A network manager can retrieve and manipulate supported variables 
in devices distributed throughout the network to control devices and diagnose problems. 

Boot Protocol. 

A system load protocol similar to EEEE 802. IE is implemented by maintaining a load file database in a 
controller. Devices can request load files by class or by name. Alternatively, a network manager can 
distribute load files to devices over the network and can cause devices to reboot with the SNMP-like 
network management protocol described above. 
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General format 


General Field Definitions 7 


16-bit Network Address Format 






Node Tvpe t 


SS TerminaJ 






L : HF Terminal 






All Terminals 






Bridge 2 


Ail Nodes i 


MAP Pnnrml Rvfp (R hirc^ * 






Bridge Control Bvtes (16 bits) \ 






Bridge Packet Types 






Optional Bridge Parameters - general format. 






Optional Parameters 






Bridge Request Packet Formats 






Data (Type 000) 






Hello (Type 010) 






Attach (Type 011) ; 






Detach (Type 100) 






Address Resolution (Type 101).* 






Reverse Address Resolution (Type 110).* 






Bridge Response Packet Formats 






Hello (Type 010)... 






Attach (Type 011) 






Detach (Type 100).......... 






Address Resolution (Type 101).* 






Reverse Address Resolution (Tvpe 1 10).* 







General format 



Pre- 


Hag 


MAC 


Bridge 


Bridge 


LLC 


LLC Data 


CRC 


Flag 


amble 




Header 


Header 


Data 


Header 
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General Field Definitions. 



Pa it n in I* 1 A 

rTeiUIiDie 


1 to X bvtes 


ritisj start delimiter 


I bvte 


.virtC ljcsu nation muuicSS 


2 bvtes 


mai_ source Auuress 


2 bvtes 


MnL V-Ullirul 


1 bvte 


DmUkC v.uiiiroi 


2 bvtes 


onuiic ucNLuiciuun Huoress 


2 bvtes 


Bridge Source Address 


2 bvtes 


Bridge Pricket Pnrms 


pacKci type dependent 


Bridge Packet Optional Parms 


M bytes 


LLC DSAP 


1 bvte 


LLC SSAP 


1 bvte 


LLC Control 


1 or 4 bytes 


LLC Data 


N bytes 


CRC-CCITT 


2 bvtes 


Has end delimiter 


1 byte 


(optional trailer) 


I or 2bytes 



16-bit Network Address Format 



bit 15 


Mulltcast Flag " 


0 


unicast frame 


1 


multicast or broadcast frame 




|bit 14-11 


Node Type 


0001 


SS Terminal 


0010 


UHF Terminal 


0011 


All Terminals 


0100 


Bridge 


1111 


All Nodes 



bit 10-0 


Node Identifier | 


all 0's 


root node identifier 


all l's 


node without a network node identifier or any node 



The well-known address of the root node is binary 0010 0000 0000 0000 (bexidecimal 2000). 
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MAC Control Byte (8 bits).* 



Bits 7-5 in the MAC control bytes are used to specify the frame type. MAC frames are one of two basic 
types: I ) request, or 2) poll, depending on the suite of the R/P bit. 

Request frame types. 



(MM) 


EOD (end-of-data) 




(MM 


DATA 




OK) 


ENO (enquiry) 




Oil 


RFP (reauest-for-Doll) 




Poll frame types 


• 






100 


WFP (wait for poll) 




101 


REJECT 




110 


CLEAR 




111 


POLL 




Request control byte: 






bit 7 


R/P 


0 = request frame 


bit 6 


DATA 


0 = data frame 


bit 5 


MORE 


1 = middle of bracket (DATA) 

0 a end of bracket (EOD) 

1 = RFP 
0 = ENO 


bit 4 


reserved 


must be zero 


bit 3 


PRIORITY 


0 = normal, 1 = high 


bit 2 


SEO 


sequence number, modulo 2 


bit 1-0 


LAN ID 


00,01, 10 or 11 


Poll control byte: 


bit 7 


R/P 


1 = poll frame 


bit 6 


WATT 


0 = wait for poll 


bit 5 


MORE 


0 = clear 


bit 4 


reserved 


must be zero 


bit 3 


reserved 


must be zero 


bit 2 


SEO 


sequence number, modulo 2 


bit 1-0 


LAN ID 


00,01, IOor 11 



NORAND CONFIDENTIAL 







83 ^ 


No rand SST Network 

Protocol Frame Format Specification 


Revision I, 2/17/92 


PACiE 5 


Bridge Control Bytes (16 bits). 




bit 15-14 


Bridge Header Format 


00 = multihop, 01 = point-to- 
point 




hit 1 ^ 


\ iCdcrvcu J 


must be zero 




hir 1 *> 

I'll 1 tm 




0 = request, 1 = response 




bit 11 


( reserved) 


must be zero 




hit 10-8 


Packet Tvpe 


(see table below) 




hit 7 


Bridge Panns 


1 = optional bridge panns 




bit 6 


RSPRQ 


1 = end-to-end response packet 
required 




bit 5-3 


Protocol 


000 = no data-link data, 001 = 
LLC data 




bit 2 


ATTI 


I=attach indication 




bit 1-0 


(reserved) 


must be zero 





Bridge Packet Types. 



000 


Data Packet 


001 


(reserved) 


010 


Hello Packet 


on 


Attach Packet 


100' 


Detach Packet . 


101 


Address Resolution Packet 


110 


Reverse Address Resolution Packet 


111 


(reserved) 



Optional Bridge Parameters - general format 



l -bit end-of-Darms flag 


1 = last optional pann 


7-bit pann tvpe 


(see table below) 


1-bvte pann length 


length of pann value field in bytes 


M-bvte pann value 


(value or list of values) 
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Optional Parameters. 



Parm Tvpe 


Parm Length 


Description | 


Olh 


2 bvtes 


A 2-bvte network address. 


02h 


6 bvtes 


Lone Identifier. 


03h 


M*2 


Decendant List. A list of 2-byte 
addresses. 


04h 


N*2 


Detached List. A list of 2-byte 
addresses. 


05h 


P*2 


Pending Message List A list of 2-byte 
addresses. 


06b 


2 bvtes 


Distance (cost) from the root. 


07b 


0 bytes 


Well-known alias. 


08b 


R bytes 


Forward List A list of 2-bvte addresses. 


09b 


1 byte 


Load Indicator. An indication of the 
channel load based on frame frequency. 


OAh 


S bytes 


Weil-known alias of the root 


OBh 


6 bytes 


Long identifier of the root 


OCh 


I or 2 bytes 


Awake time (in 100 millisecond units). 
All l's denotes forever. 


ODb 


1 or 2 bytes 


Awake time offset (in 100 millisecond 
units). 


OEh 


1 byte 


Delivery service type, 

0=deli ver immediately. 
l=store until the node is awake. 
2=attempt to deliver immediately, then 
store until the node is awake. 


OFh 


1 byte 


Maximum stored message count The 
maximum number of hello times that the 
parent node should store a message for 
the source child node. 


lOh 


2 bytes 


Decendent count 
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Data (Type 000). 


MAC Header 




Bndijina Header 




Optional Bridging Parms 


N bytes 


- Max. stored message count. 


- Delivery service type. 




- Wake up time. 




- Wake ud time offset. 




LLC Header (optional) 




LLC Data (optional) 




Hello (Type 010). 




MAC Header 




Brideine Header 



Attach (Type 011). 



MAC Header 




Bridging Header 




Optional Bridging Parms 


N bytes 


- Decendant list 


• Max. stored message count 




- Delivery service type. 




- Wake up time. 




- Wake uo time offset 




LLC Header (optional) 




LLC Data (optional) 




Detach (Type 100). 


MAC Header 




Bridging Header 




Optional Detach Parms 


N bytes 


- Decendant list 


- Forward list 
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Address Resolution (Type 101). 



MAC Header 




Bndeine Header 




ARP Operation 


1 byte 


bit 7-4 (reserved) 
bit 3-0 reason code 


must be zero 

0 = ok. other = error code 


Network Address 


2 bvtes 


Lone ID/ Alias tvoe 


1 bvte 


Lone ID/ Alias length 


I bvte 


Lone ID/ Alias 


N bvtes 



*The Long ID/Alias can be a 6-byte identifier or an Alias. The address server will set the network address 
field to the network address of the associated node. If the Long ID (or Alias) cannot be found the network 
address field will be set to ail l's. 



Reverse Address Resolution (Type 110).* 



MAC Header 




Brideine Header 




RARP Operation 


1 byte 


bit 7 New Alias 
bit 6 New Long ID 
bit 5 (reserved) 
bit 3-0 reason code 


1 = replace existing Alias 
1 = replace existing Long ID 
must be zero 

0 = ok, other = error code 


Network address 


2 bvtes 


Lone ID tvpe (02h) 


I byte 


Lone ID length (6) 


1 byte 


Lone ID 


N bvtes 


Alias type (07h) 


1 bvte 


.Alias length 


I byte 


Alias 


N bytes 



*The requesting node must set the Long ID field and/or the Alias field. The source bridge address must be 
set to the source node type and a node ID of all l's. The address server will set the network address field 
to the next available 16-bit address. If an address is not available, the field will be set to ail l's. 
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Bridge Response Packet Formats. 



Hello (Type 010). 



mac Heauer 




Bridging Header 




Cost-to-root 


2 bvtes (OxFFFF = infinity) 


Seed/ Attach priority 


1 hvfe 


bit 7-2 seed 


i 


bit 1-0 attach priority 


00 = lowest priority 


Offset 


1 byte 




0-254 = transmission offset time in 




hundredths of seconds. 




255 = unscheduled. 


Root Priority 


1 byte 


bit 7-6 reserved 


(must be zero) 


bit 5-3 user priority 


000 = lowest priorty. 


bit 2-0 device priority 


000 = lowest priority. 


Root ID Sequence Number 


I byte 


Optional fields 


N bytes 


- Root ID 




- Pending Message List 




- Decendant Count 




- Detached List 




- Load Indicator 




Attach (Type Oil). 




MAC Header 




Bridging Header 




Detach (Type 100). 




MAC Header 




Bridging Header 
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Address Resolution (Type 101).* 



MAC Hender 




Brideine Header 




ARP Operation 


1 byte 


bit 7-4 (reserved) 
bit 3-0 reason code 


must be zero 

0 = ok, other = error code 


Network Address 


2 bvtes 


Lone ID/ Alias type 


I bvte 


Lone ID/ Alias leneth 


1 byte 


Lone ID/ Alias 


N bvtes 1 



*The Long ID/ Alias can be a 6-byte identifier or an Alias. The address server will set the network address 
field to the network address of the associated node. If the Long ID (or Alias) cannot be found the network 
address field will be set to all l's. 



Reverse Address Resolution (Type 110).* 



MAC Header 




Brideine Header 




RARP Operation 


I byte 


bit 7 New Alias 
bit 6 New Long ID 
bit 5 (reserved) 
bit 3-0 reason code 


1 =j replace existing Alias 
1 = replace existing Long ID 
must be zero 

0 = ok, other = error code 


Network address 


2 bytes 


Lone ID tvpe (02b) 


I byte 


Lone ID leneth (6) 


1 byte 


Lone ID 


6 bytes 


.Alias type (07b) 


1 byte 


.Alias leneth (N) 


1 byte 


.Alias 


N bytes 



The requesting node must set the Long ID field and/or the Alias field. The source bridge address must be 
set to the source node type and a node ID of all l's. The address server will set the network address field 
to the next available 16-bit address. If an address is not available, the field will be set to all l's. 
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Introduction t 

Functional Requirements ■> 

Bridge Packet Definitions 2 

Constants, timers and data structures 5 

Suite Transition Logic - notation and assumptions 7 

Root Resolution Protocol ^ 

Attaching to the Spanning Tree 1 \ 

Reliable Flooding Mechanism 16 

Spanning Tree Link Maintenance and Recovery 16 

Network Routing : 2 1 

Address Resolution and Maintenance; 22 

HELLO Timing 25 

Sleeping terminal support 28 



Introduction. 

This document, in conjunction with the SST network frame format specification, defines the 
routing layer protocol used with the SST network. 



Functional Requirements. 

The bridging layer 

- selects a root bridge node. 

- organize nodes in the network into an optimal spanning tree rooted at the root bridge. 

- routes tenninal-to-terminal data traffic along branches of the spanning tree. Note that a host 
computer is treated as a terminal. A routing table is maintained in each bridge node for ail 
upstream nodes. The path to downstream nodes is inherent in the structure of the spanning 
tree. 

- provides a service for storing packets for SLEEPING terminals. 

- propagates lost node information throughout the spanning tree. 

- maintains the spanning tree links. 

• distributes network interface addresses. 

- organizes nodes into logical coverage areas on radio channels. 



Bridge Packet Definitions* 
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Bridge Control Byte Fields. 



Bridge header format - This field is used to define the format of the bridge header. 

00 = multihop. This is the normal bridge header format. The bridge header includes 
source and destination address fields. 

01 = point-to-point. The bridge header does NOT include source and destination 
address fields. 

Packet type - This field is used to specify the bridging layer packet type. 

Bridge parms - If this bit field is set ON then optional bridging layer parameters immediately 
follow the bridge header. 

RSPRQ - This field can be used to request an end-to-end bridging layer response packet. 
Normally this field should be set ON for ATTACH, RARP and ARP request packets, and 
should be set OFF for all other bridging layer packets. 

ATTI - A bridge node will set this bit ON in an ATTACRrequest packet whenever the 
source node is not in the bridge's routing table. The bit value in an ATTACH.response packet 
follows the state of the bit in the associated ATTACRrequest packet received by the root 
node. If a terminal receives an ATTACH.response packet with the ATTI bit set ON, it is a 
positive indication that the terminal was detached and has reattached to the network. 

Protocol - This field is used to indicate the presence and type of higher layer data. 

000 = no higher layer data is contained in the packet. 

001 = an LLC message is contained in the packet. 
010 = an NNMP message is contained in the packet. 



Bridge Packet Types. 



DATA, request 

DATA.request packets are general purpose bridging layer packets used to send higher layer 
data and/or bridging layer parameters. 

A child node can periodically send a (possibly empty) DATA.request packet to its parent to 
ensure that it is still attached to the spanning tree. Note that an ATTACRrequest packet, with 
the ATTI bit set ON, is generated by a bridge node whenever the bridge node receives a 
downstream D ATA .request packet and the source of the DATA packet is not in the bridge's 
routing table. 



HELLO.request 
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A HELLO.request packet is used to solicit unscheduled HELLO.respunse packets from bridge 
nodes. A HELLO request packet can be broadcast by an unattached node when it wants to 
quickly reattach to the network. 

HELLO, response. 



HELLO.respunse packets are sent periodically at calculated time intervals by all bridge nodes. 
In addition, bridge nodes will broadcast a HELLO.response packet whenever a 
HELLO.request packet is received. HELLO.response packets are used to build the spanning 
tree and are used to advertise pending message information and lost node information. 



ATTACH, request 

A node transmits an ATTACRrequest packet, with the RSPRQ bit set ON, to attach to the 
network. In addition, a node must transmit an ATTACRrequest packet at least once per 
ATTACH JTIMEOUT time period to maintain its path in the network. All ATTACHxequest 
packets are implicidy forwarded to the root bridge node. If the RSPRQ bit is set ON the root 
bridge node will return an ATTACRresponse packet 

Higher layer data can be piggybacked onto ATTACH.request packets by setting the bridging 
layer destination address to the 16-bit address of the node for which the data is intended. If 
data is piggybacked onto an ATTACH.request packet the bridging layer will split the 
ATTACH packet into separate ATTACH and DATA request packets as soon as the next hop 
to the destination address is not on the path to the root node (i.e. the first upstream hop). The 
destination address of the generated ATTACH.request packet is the well-known address of the 



If a bridge node receives a downstream DATA.request packet and the source node is not in the 
bridge's routing table, then the bridge node will automatically generate an ATTACHj-equest 
packet, with the ATTI bit set ON, for the source node and forward it to the root node. The 
source address in the generated ATTACH.request packet is the same as the source address in 
the DATA packet. (Note that the DATA packet can simply be converted to an ATTACH 



A TTACH. response. 

The root node will return an ATTACRresponse packet to the source node in the associated 
ATTACRrequest packet if the RSPRQ bit in the request packet is set ON. The ATTI bit will 
be set ON if the originating node was not fully connected to the network (i.e. if the node was 
not in the routing table of a bridge node on the path of the request packet). 



Detach, request 

DETACRrequest packets are used to notify the network that a node has detached. 
DETACRrequest packets can be reliably broadcast throughout the spanning tree by using the 
reliable flooding mechanism described below. If a DETACRrequest packets includes a 
decedent list, then all nodes in the decedent list and the bridging layer source node are purged 
from the routing table of nodes which receive the request. 



root node. 



packet.) 
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Address Resolution Packet (ARP). 

An iddress resolution packet is used to acquire the 16-bit network address of a destination 
node when only the alias or 48-bit identifier of the node is known. 16-b.t network addresses 
•ire c'iched by the bridging laver. An ARP packet is generated automatically by the bridging 
layer whenever it receives a send request for which the destination is not in its cache. 

Reverse Address Resolution Packet (RARP). 

A RARP packet is used to set or change the ajias and/or 48-bit long identifier of a device and 
to acquire a 1 6-bit network address. 



Constants, timers and data structures. 

ROOT.ADDRESS = hex 2000; 

HELLO_RETRY = 5: 

MAX_HELLO_LOST = 8; 

HELLO_SLOT_SIZE = .020 seconds. 

HELLO_MOD_VAL = 67. 

AVG_HELLO_SLOTS = 100. 

MIN.HELLO.SLOTS = HELLO_MOD_V AL. 

MAX HELLO SLOTS = (HELLO_MOD_V AL * 2) - 1. 

AVG"HELLO "PERIOD = HELLO.SLOT.SIZE * AVG.HELLO SLOTS seconds; 
MIN "HELLO "PERIOD = HELLO SLOT.SIZE * MIN.HELLO.SLOTS seconds; 
mS(" ffi^LO PEWOD = HELLO"_SLOT_SIZE * MAX.HELLO.SLOTS seconds; 
rCELLO_TIMEOUT = HELLO_RETRY • AVG_HELLO_PERIOD + 1 seconds; 
S HELLO_WAIT = .5 seconds; 
MAX.HELLO.OFFSET = 200 milliseconds; 

BRG_RSP_TTMEOUT = 10 seconds; 

HOLD.DOWN.TIME = MAX_HELLO.PERIOD*(MAX_HELLO_LOST + 2) seconds; 

DEF_SAVE_CNT = 3; 

MAX_SAVE_CNT = 5; 

AW AKE.TTME.UNTT = . 1 seconds. 

ADDRESS_TTMEOUT = 30 minutes. 
MAX.ADDRESSJJFE = 120 minutes. 

NETWORKJTTMEOUT - 12 minutes. 

ROUTE.TIMEOUT = 10 minutes. 
ATTACH_TIMEOUT = 8 minutes. 

UT OOR TIME = 20 seconds; (Unattached terminal out-of-range list entry timeout) 
UB _ 00r"tTME = 100 seconds; (Unattached bridge out-of-range list entry timeout) 
AT'OORTIME = 100 seconds; (Attached terminal out-of-range hst entry timeout) 
Ab"00r"t1ME = 300 seconds; (Attached bridge out-of-range list entry timeout) 
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UT OOR_AGED_TIME = 300 seconds: ( Atuiched terminal out-of-range list aged entry 

timeout) 

UB OOR_AGED_TTME = 500 seconds: ( Atuiched bridge out-of-range list aged entry 

timeout) 

AT OOR AGED.TIME = 500 seconds: (Atuiched terminal out-of-range list aged entry 

timeout) 

AB.OOR AGED.TIME = 1000 seconds: (Atuiched bridge out-of-range list aged entry 

timeout) 

B_ENABLE_WAIT = 20 seconds; 
R IDLE.TIME = 60 seconds: 
MAX_RARP_RETRY = 10; 
MAX _ ATT ACH_RETR Y = 5; 

B_TIMEOUT; ( Bridging layer timeout value - a tuncuon ot the cost to the root. ) 

HOP_COST_ETHER = 20; 
HOP_COST_485LAN = 40; 
HOP_COST_SSRADIO= 125; 
HOP_COST_BUS=0; 

OOR_COST = 75; 

A hello-timer is used to measure a HELLO learning period. 

An Inactlvlty-tlmer is used to measure periods of network inactivity. 

A path-timer is used to measure the maximum round-trip path delay for bridging layer 
packets which require a response. 

In any enabled state, all nodes, except the root, maintain two lists: an In-range list and an out- 
of-range list 

An entry in the in-range list contains the network address of a bridge node which was the 
source of a HELLO packet, the port used to communicate with the bndge ■ ^"«« 
fetor, and pad, cost mformauon. Each entry in the m-range list * aged so ^ * * scarded 
if no HELLO packet is received from the associated bndge within HELLO - T ^° a U L LLO 
seconds. The aging factor for an entry in the in-range list is reset to zero whenever a HELLO 
packers receded 'The aging factor for the entry of the parent "ode is "set to «J 
any packet is received from the parent In-range entries are ctawfed ai 0^f«™ 
HELLO periods pass without receiving a HELLO packet from the bndge specified in the 
entry. 

An entry in the out-of-range list contains the network address of a bridge node, the port used 
to eorZnicate with the bridge, and an aging factor. 2£* £ ^ ^ 

remember failed paths when a node is attempung to attach to the network. Entnes in the tat 
^ge* o indi .L how long entries have been in the list. Out-of-range entn« > » ctagkd 
» OLD after two HELLO periods in the Use Out-of-range entnes are dassif.ed as AGED 
afterOOR TIME seconds to the list AGED entries which are also in the 001 
selected as a potential parent node unless no other in-range entnes are available. AGED 
entries are discarded after OOR_AGED_TTME seconds have passed. 

Each node maintains a current.root variable, which is initialized to NULL. The variable 
conLns the priority, root sequence, and ROOT ID the currenUy active root "ode -here 
ROOT ID is a.48-bit device ID and/or alias. The variable is used to remember the current root 
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node. Attached nodes detach and go into an initial unattached state, without a network 
address, when the root node changes. 

In general, an entry Is added/updated in the in-ran^e list of an enabled, attached or 
unattached node whenever a HELLO packet with the priority, sequence, and identifier 
of the current root node, is received, and the source bridge is not in the node s out-of- 
ranjje list. 

Each node, except the root, maintains a current.parent variable, which contains the network 
address and path cost information of the current parent of the node when the node is in an 
attached suite. 

MSG .PENDING is (conceptually) a global state variable which is true when an incoming 
message is expected. 



State Transition Logic - notation and assumptions. 
Assumptions. 

The state transition logic in this document and the SST network assumes the following: 

- All nodes are assigned a LAN ID. 

. Packets which do not belong to the network specified by a node's LAN ID are discarded by 
the MAC layer arid are not passed to the bridging layer. . r _ nc „ 

- In any enabled state, all nodes store information derived from received HELLO .response 

P HELLO.response packets with a cost-to-root field value of 0 are from the root node. 
. All nodes remain awake in any enabled unattached state. If SLEEPING nodes are unable to 
attach to the network after a maximum awake time has expired, an error is returned to a higher 
layer, and retries are handled by the higher layer. 

- Root candidates must have a direct-link host port. 

- All root candidates should be wired together. 

. A node loses its address and goes into an intermediate hold-down state whenever a new root 
node is detected. 

State Notation. 

State names used in this document are hierarchical. Suffixes are added to state identifiers to 
further refine a state definition. An unqualified high-order prefix may be used to reterence all 
possible substates. 

The bridging entity in each node is in one of the following high-level node states. 

R .Root node. The node owns the root node address. 

RC - Root candidate node. The node does not have an address. 

BB - Bridge node with a root priority of zero. 

BR - Bridge node which has a non-zero root priority. 

B - Any Bridge node. 

T - Terminal node. 

* - any node. 
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■i • subscript used to qualify a node state to indicate that the node does not have a network 
address. For example, T a is used to specify a terminal node that does not have a network 
address. 

All node states are further qualified by one of three attach states: 

D - The node is Disabled and unattached. 
U - The node is enabled and Unattached. 
A - The node is enabled and Attached to the network. 

A node can be in an intermediate hold-down state: 

I - The node is in an Intermediate hold-down state. Bridge nodes, which were attached, 
transmit HELLO.response packets with an infinite cost in the intermediate state. 

As an example. RC.U, is used to denote the node and attach state of a root candidate which is 
not attached to an SST network. 

The following substates are used to qualify an unattached node: 

idle - No network activity has been detected, 
wait - Wail for the first HELLCresponse packet, 
hello - A HELLO.response packet has been received, 
rarp - An address request is in progress, 
attach - An attach request is in progress. 



Root Resolution Protocol. 

Each SST network must have one or more root candidates. Each root candidate node enters a 
RC.U state when the bridging entity in the node is enabled. This state ends when 1) the root 
candidate determines that a higher priority root node already exists and enters the BR.U state 
or 2) the root candidate assumes ownership of the root node status and enters the R.A state. A 
node in any BR state assumes the root node status if 1) the network becomes idle, or 2) a 
lower priority root node is detected. 

A root candidate which does not detect any activity assumes the root node status. If activity is 
detected, the root candidate remains in the RC.U.wait state until a HELLO .response packet is 
received or until network activity ceases. 

When an unattached non-candidate node receives its first HELLO.response packet it enters the 
♦.U.hello state, and sets a hello-timer used to measure a HELLO learning period. The hello- 
timer expires after HELLO.RETRY HELLO periods. 

In the R A state the root node broadcasts a HELLO response packet once per 
HELLO PERIOD time period, according to a random distribution algorithm. The root 
HELLo7response packets contain a path cost of 0. the priority of the root node, a root ID 
sequence number, and a ROOT ID which is either the unique >ong idenufier or the unique 

the root device. The priority, ROOT ID sequence, and ROOT ID fields are cop.ed 
into the HELLO.response packets transmitted by all non-root bridges in the network. 
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A ROOT ID sequence number is stored in non-volatile storage by all root candidates. The 
sequence number is copied into RAM by the root node when it determines that it is the root 
and the copv in non-volatile storage is incremented. The copy in RAM is included in all 
HELLO.response packets broadcast by all attached bridge nodes in the spanning tree. 



Hello packet priority. 

A "higher priority HELLO.response packet" is defined as any HELLO.response packet which 
contains a matchinc LAN ID and either I) a higher concatenated USER PRIORITY-DEVICE 
PRIORITY field, or 2) an equal priority field and a higher priority ROOT ID. A ROOT ID 
can consist of a unique 48-bit device ID and/or a device alias. A "higher priority ROOT ID" 
is defined as I) the ID with the higher 48-bit ID. or, 2) if neither candidate has a 48-bit ID. the 
ID with the alias with highest string value. Note that if the ROOT ID does not contain a 
unique 48-bit device ID, then the 48-bit device ID is assumed to be all O's. 

It may be possible for a root candidate to receive a HELLO.response packet with an equal 
priority if the ROOT ID field in the HELLO.response packet matches the candidate s device 
identifier. HELLO.response packets with a ROOT ID field that matches the identifier of the 
local device and a non-zero path cost are assumed to be associated with an out-of-date 
spanning tree and are discarded by the bridging layer. A matching ROOT ID and a zero path 
cost causes a fatal error. 
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Root resolution state transition table. 

The suite transition table below defines transitions m the root resolution process. 



Mate 
RC.D 



RC.U.idle 



event 

Bndging entity enabled. 



Inactivity-timer expires. 



Non-HELLO packet received. 

Higher priority HELLO 
packet received. 




ncuon 

Enable MAC on all network 
ports; set HELLO.TIMEOUT 
inactivity-timer. 



Set R JDLEJTIME 
inactivitv-timer. 
Set RJDLEJTIME 
inactivity-timer set 
HELLOJTIMEOUT hello- 
timer. 



Set R_IDLE_TIME 
inactivity-timer. 



next suite 
RC.U.idle 



R.A 
RC.U.wait 



Higher priority HELLO 
packet received. 



Set R_IDLE_TIME 
inactivity-timer, set 
HELLO JTIMEOUT hello- 
timer 



Lower priority HELLO 
packet r eceived 



pacKci rctcivcu. 
Lower priority HELLO 

packet received. 

Higher priority HELLO 
packet received. 



Set R JDLE JTTME 

inactivity-timer 

Transmit HELLO packets 
with an infinite path cost for 
MAX_HELLOJ-OST+l 
HELLO periods; set 
RJDLEJTIME inactivity- 
timer, set 

HELLO JTIMEOUT hello- 
timer . 



BR.I then 
RC.U.wait 
R.I then 
BRa.U.hello 
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Attaching to the Spanning Tree. 

Nodes learn the best path to the root node by listening to HELLO.response packets from 
•tttached bndge nodes. Alter a learning time expires, a node without a network address sends 
•i R-\RP request packet to the attached bridge, in the in-range list, which provides the best 
path to the root. A node with a network address sends an ATTACH.request packet to the 
attached bndge in the in-range list which provides the best path. The "best path is primarily 
a function of the path cost to the root. 



Attach Selection Criteria. 

The criteria tor selecting a parent bridge node as the first hop in a best path is defined as 
follows- 1) first, only nodes which are in the in-range list, and not in the out-ot-range list, are 
considered: 2) if no such node exists, then nodes which are in the in-range list but are 
classified as AGED, in the out-of-range list, are considered; 3) the node with the lowest cost to 
the root is chosen from the set of "parent candidates"; 4) if two or more nodes have the same 
path cost, then the node with the best signal strength is chosen (if a signal strength indicator is 
available); 5) if both the path cost and signal strength are equal, then the node w,th the highest 
attach priority is chosen; 6) if the path cost signal strength and attach priority are equal, then 
^node with the lowest network address is chosen. Elements 5 and 6 of the selection^ cntena 
are intended to group terminals into logical coverage areas under the control of a single bndge 
™de rather than allowing terminals to randomly attach to any bndge node when physical 
coverage areas overlap* 

All parent candidates must be in the in the in-range list. New entries in the out-of-range list 
ore nTconsidered as parent candidates. If no parent candidates exist an unattached node can 
wL and listen, or. opdonaUy. can solicit short HELLO.response packets by transmitting a 

global HELLO.request packet. 
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Bridge Attach State Transitions. 



The suite transition table below defines the suite transitions required for a disabled bridge 
node to obtain a network address. Note that a root candidate enters the B a .U.hello state after 
learning of a higher priority root. 



event „ 

Bridging layer is enabled. 



action 



next suite 



BB.D 



Enable MAC on all network 
ports; initialize in-range list to 
NULL; initialize out-of-range 
list to NULL. 



B~.U.wait 



B n .U.wait 



HELLO packet received from 
the root. 

HELLO packet received from 
a non-root bridge. 



Send RARP.request to the 
root; set B_TIMEOUT patb- 
timer: set retry count to 1. 
Set hello-timer. 



B n .U.rarp 



B a .U.hello 



B~.U.hello 



B n .U.rarp 



Hello-timer expires or 
HELLO packet received from 
the root node. 

RARP.response packet 
received. 



Send RARP.request to the 
attached bridge with the best 
path; set BJTIMEOUT path- 
timer: set retry count to 1 
If address was received send 
ATTACH.request to the 
attached bridge with the best 
path; set BJTIMEOUT timer, 
set retry count to i. 



Ba.U.rarp 



If address was 
received then goto 
B.U.attach else 
post error goto 
BB.D or RCD. 
B a .U.rarp 



path-timer expires. 



Resend RARP .request. 
Increment retry count 



Retry count > 

MAX RARP RETRY. 



Initialize in-range list to 
NULL. 



MAC layer retry error. 



Add respective bridge to out- 
of-range list Delete bridge 
from in-range Usl If list is 
not empty, send a 
RARP.request to the attached 
bridge with the best path; set 
BJTIMEOUT timer, set retry 
count to 1. 



If in-range list is 
empty then goto 
B n .U.wait else 
goto B^.U.rarp 
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The transition table below defines the state transitions required tor an unattached bridge node, 
with a network address, to attach to the network. Note that an attached bridge node enters the 
B.U.wait state after detaching from the network. An unattached bridge node enters the 
B.U.attach state after receiving its network address. 



suite 


event 


action 


next state 


O IT n/'i i r 
D. U . WtUl 


HELLO packet received from 
the root. 


Send ATTACH.request to the 
root: reset B .TIMEOUT 
timer: set retrv count to I. 


B.U.attach 




HELLO packet received from 
a non-root bridee. 


Reset hello-timer. 


B.U.hello 


D • \J .L1CIIU 


He Ho- timer expires or 
HELLO packet received from 
the root node. 


Send ATTACH.request to the 
attached bridge with the best 
path: reset B.T1MEOUT 
timer: set retrv count to 1. 


B.U.attach 


B.U.attach 


ATTACRresponse packet 
received from bridge with 
best path in in-ranee list 




B.A 




ATTACRresponse packet 
received from bridee other 
than one with best path. 


(ignore) 


B.U.attach 




B .TIMEOUT timer expires. 


Resend ATTACH request. 
Increment retrv count. 


B.U.attach 




Retry count > 

MAX ATTACH RETRY. 


Initialize in-range list to 
NULL. 


B.U.wait 




MAC layer retry error. 


Delete bridge from in-range 
list. If list is not empty, send 
an ATTACRrequest to the 
attached bridge with the best 
path; set B.TIMEOUT timer; 
set retrv count to I . 


If in-range list is 
empty then goto 
B.U.wait else goto 
B.U.attach 




HELLO packet received with 
shorter path cost and not in 
out-of-range list 


Send ATTACH.request to 
the attached bridge with the 
best path; reset B.TIMEOUT 
timer; set retrv count to 1. 


B.U.attach 



Note that the ATTACRrequest packets, specified in the above transition tables, require an 
end-to-end response (i.e. an ATTACRresponse packet). 

Stole transition tables for an unattached brid R e node which has a non-zero priority 
(BR U) are identical to the above state tables for bridges with a priority of zero, with the 
following exceptions: 1) An unattached bridge with a non-zero priority assumes the root node 
status whenever no packets are received within an RJDLE.TIME inactivity period in any 
state: 2) an unattached bridge with a non-zero priority enters the RC.U.wait state, after a BR.I 
hold-down period, whenever a lower-priority HELLO message is received. Note that an 
inactivity-timer is constantly running and must be reset whenever a packet is received. 

In any attached or unattached state, a bridge loses its address, waits for a hold-down period, 
and then goes to a *.U.wait state, whenever a new root node is detected. 
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Terminal Attach State Transitions. 



The state transition table below specifies the suite transitions required tor a disabled 
node to attach to the network. 



suite 


event 


action 


next suite 


T.D 


Bridging layer is enabled. 


Enable MAC on all network 
nnrK* initialize in -ranee list to 
NULL; initialize out-of-range 
list to NULL; set 
HELLO .TIMEOUT hello- 
timer. 


Ta.U.wait 


T ; ,.U.wait 


HELLO packet received from 
the root. 


Send RARP.request to the 
root; set B JTIMEOUT timer, 
setretrv count to 1. 


T n .U.rarp 




HELLO packet received from 


Reset HELLO JTIMEOUT 
hello-timer. 


T a .U.hello 




Hello-timer expires. 


(sleep); reset 

HELLO ^TIMEOUT hello- 
timer. 


T a .U.wait 


T n .U. hello 


rteiio-uincr CApuca ui 
HELLO packet received from 
the root node. 


Send RARP.request to the 
attached bridge with the best 
path; set B.TIMEOUT timer 
setretrv count to 1. 


Tn.U.rarp 


Tn.U.rarp 


RARP .response packet 
received. 


If address was received send 
ATTACH.request to the 
attached bridge with the best 
path; set BJTIMEOUT timer 
setretrv count to I. 


If address was 
received then goto 
T.U.attach else 
post error goto 
T.D 




BJTIMEOUT timer expires. 


Resend RARP request. 
Increment retrv count. 


Tn.U.rarp 




Retry count > 

MAX RARP RETRY. 


Initialize in-range list to 
NULL. 


Ta.U.wait 




MAC retry error. 


Add respective bridge to out- 
of-range list Delete bridge 
from in-range list If list is 
not empty, send a 
RARP.request to the attached 
bridge with the best path; set 
BJTTMEOUT timer set retry 
count to 1. 


If in-range list Ls ; 
empty then goto | 
Ta.U.wait else 
goto T n .U.rarp 



In anv attached or unattached state, a terminal loses its address, waits for a hold-down period, 
and then goes to the T a .U.wait state, whenever a new root node is detected. 
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The transition table below defines the suite transitions required tor an unattached terminal 
node, with a network address, to attach to the network. Note that an attached terminal node 
enters the T.U.wait state at'ter detaching from the network. It the terminal has a message 
pending, then the terminal will solicit short HELLO.response packets with a global 
HELLO.request, and will wait HELLO.WAIT seconds tor a HELLO packet. 



.state 


event 


action 


next state 


T.U.wait 


rLCL.L.U ptlLKCl ICL-C1VCU LiUlll 

the root. 


Send ATTACH reauest to the 
root; set B.TIMEOUT timer 
set retrv count to I. 


T.U.attach 




HELLO packet received from 

a nun-ruui nnuiic. 




T.U.hello 




Hello-timer expires. 


Pause (and sleep); send global 
HELLO.request; increment 
retry count ; Reset 
S_HELLO_WAIT hello- 
timer. 


T.U.wait 




Hello-timer expires; retry 
count ^ 

MAX HELLO WATT. 


Return uncompleted requests 
with error. 


Ta.U.wait 


T Tf kAlIn 


WpHn-Mnif*r pxnires or 

HELLO packet received from 
the root node. 


Send ATTACH.request to the 
attached bridge with the best 
path; set BJTIMEOUT timer; 
set retrv count to I . 


T.U.attach 


T.U.attach 


ATTACRresponse packet 
received from bridge with 

K*»ct narh in in.ri*no*» lief 


Set current_parent to best 
path bridge. 


T.A 




ATTACH .response packet 
received from bridge other 
than one with best path (i.e. in 
response to an old request). 


(ignore) 


T.U.attach 




BJTIMEOUT timer expires. 


Resend ATTACRrequest; 
increment retry count 


T.U.attach 




Retry count > 

M AX_ ATT ACH_RETR Y . 


Initialize in-range list to 
NULL; send global 
HELLO.request; set retry 
count to 1; Set 
S_HELLO_WAIT hello- 
timer. 


T.U.wait 




MAC layer retry error. 


Move bridge from in-range 
list to out-of-range list 

If in-range list is empty, send 
a global HELLO request; set 
S_HELL0_WA1T hello- 
timer set retry count to 0; 

else, if in-range list is not 
empty, send an 
ATTACH.request to the 
attached bridge with the best 
path; set B.TIMEOUT path- 
timer; set retrv count to 1 . 


If in-range list is 
empty then 
T.U.wait 

else T.U.attach 
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Better path found. 


Send ATTACH.request to 
the attached bridge with the 
best path; set B JTIMEOUT 
path-timer, set retry count to 
1. 


T.U.attacb 



In ;my attached or unattached suite, a terminal loses its address, waits tor a hold-down period, 
;md then goes to the T a .U.wait state, whenever a new root node is detected. 



Reliable Flooding Mechanism. 

Information can be flooded throughout the network by using a "rehable flooding mechanism". 
A node can flood a bridging layer request packet 1) by setting the MAC layer and bridging 
layer destination addresses to all l's (i.e. a global address), 2) by setting the RSPRQ bit ON, 
and 3) by including a forward list in the packet. The forward list is identified by the bridging 
layer parameter type hexadecimal 08. It is used to specify which nodes must forward and 
acknowledge the request Initially, the forward list consists of all bridge nodes which are 
either children or the parent of the node which generated the packet Nodes in the forward list 
acknowledge the request packet with a unicast response packet of the same packet type. Note 
that only one flooded packet of a given type may be outstanding at a time. If a receiving node 
in the forward list is attached to one or more branches of the spanning tree, other than the 
branch on which the request packet arrived, then the node must rebroadcast the request packet 
The forward list in the rebroadcast packet will consist of each bridge node which is the first 
hop on such other branches.' Note that the forward list may be empty if the first (and only) 
hop in all other branches is a terminal node. 



Spanning Tree Link Maintenance and Recovery. 

A link in the spanning tree is lost whenever one of the following events occurs: 

1 ) A child node is unable to deliver a message to its parent bridge node. 

2) A child node finds a better path to the root node. 

3) MAX_HELLCLLOST consecutive HELLO response packets from a parent bridge node are 

lost by a child node. . 

4) A HELLO response packet, from a parent bridge node or current root node, with an infinite 

path cost is received by a child node. 

5) A HELLO.response packet is received with a new ROOT ID or Root Sequence Number. 

6) An attached node, which is not in a "DETACH HOLD.DOWN" state, receives a DETACH 
packet or HELLO.response packet with its address in the packet s detached node list 

7) A parent node is unable to deliver a message to a child node. 
X) A routing table entry is aged and deleted. 

- Response actions to events 1-6 are defined in the detach state transition tables below. 

- Event 7 is discussed in the section which describes detach packet logic. 
. Event 8 is discussed in the section on routing table maintenance. 
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Detach State Transitions. 



Terminal Detach State Transitions. 



The transition table below defines events which may cause a terminal to detach from the 
network. 



suite 


event 


action 


next suite 


T.A 


MAC_send error. 


Remove old entries and the 
destination bridge from the 
in-range list; initialize the 
out-of-range list to the MAC 
destination bridge; 

If the in .range list is empty, 
send global HELLO.requesu 
set S_HELLO_WAIT hello- 
timer; set retry count to 1 ; 

else, if in-range list is not 
empty, send an 
ATTACH.request to the 
attached bridge with the best 
path; set B_TIMEOUT path- 
timer set retry count to 1. 


[f in-range list is 
empty then 
T.U.wiui 

else T.U.attach 




Terminal address seen in a 
detached node list in a 
DETACH packet or HELLO 
pacicei ana current tune is 
past HOLD.DOWN. 


Remove old entries from the 
in-range list; add the source of 
the DETACH or HELLO 
pacKci to me in-nmgc nsi, 
initialize the out-of-range list 
to NULL; send an 
ATTACH.request to the 
attached bridge with the best 
path; set B.TIMEOUT path- 
timer; set retry count to 1; set 
HOLD_DOWN to current 
time plus 

HOLD_DOWN_TIME. 


i . u .attacn 




Better path found to the root 
and no data transactions are 
pending. 


Issue a MAC_enquiry to the 
best path bridge. 


T.A 




Positive response to a 
MAC.enquiry received from 
the best oath bridge. 


Send an ATTACH request to 
the destination bridge. 


T.U.attach 




Negative response to a 
MAC_enquiry. 


Move the destination bridge 
from the in-range list to the 
out-of-ranee list. 


T.A 
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MAX_HELLO_LOST 
consecutive HELLO packets 
from the parent node are 
missed. (Note that sleeping 
terminals must count skipped 
HELLO times as misses.) 


Send an ATTACH.request to 
the attached bridge with the 
best path; set B .TIMEOUT 
path-timen set retry count to 
1. 


T.U.attach 




HELLO packet received from 
parent with an infinite path 
cost(siune ROOT ID). 


Remove parent and old 
entries from the in-range list; 
remove old entries from the 
out-of-range list; set 
HELLO.TIMEOUT HELLO 
timer. 


T.U.wait 




HELLO packet received with 
new ROOT ID or Root 
Sequence Number 


Update current-root. 
Initialize node identifier to all 
l's. Initialize in-range and 
out-of-range lists to NULL. 


T,.U.waa 



A sleeping terminal should remain awake, whenever a threshold number (i.e. 1 or 2) 
consecutive HELLO packets have been missed from its parent node, until a HELLO packet is 
received from its parent or until the terminal detaches and reattaches to a different parent 
node. 



A terminal which is waiting to receive a response time critical message can periodically 
transmit an empty DATA.request packet to its parent bridge node, to determine if the parent is 
still in range, if the message is not received in the expected amount of time. 

A terminal which is in a DETACH HOLD.DOWN state must send an ATTACH.request 
packet to the root node after the HOLD.DOWN state ends, to ensure that it is fully attached to 
the network. 



Bridge Detach State Transitions. 

The transition table below defines events which may cause a bridge node to detach from the 
network. The "detach" action, specified in the table, consists of broadcasting infinite cost 
HELLO packets for MAX_HELLO_LOST+l HELLO periods, in an intermediate detach 
(B.I.detach) state before going to an unattached state. 
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state 


event 


action 


next state 


B.A 


MAC_send error. 


Detach. Remove the MAC 
destination and old entries 
from the tn-range list; 
initialize the out-of-range list 
to the MAC destination 
bridge; set 

HELLO JTIMEOUT hello- 
timer. 


B.U.wait 




Bridge address seen in a 
detached node list in a 
DETACH packet or HELLO 
packet. 


Detach. Remove old entries 
from the in-range list; add the 
source of the DETACH or 
HELLO packet to the in- 
range list; initialize the out- 
of-range list to NULL; set 
HOLD.DOWN.TIME hello- 
timer. 


B.U.wait 




Better path found to the root. 


Issue a MAC_enquiry to the 
best path bridge. 


B.A 




Positive response to a 
MAC_enquiry received from 
the best oath bridee. 


Send an ATTACH.request 
with a decedent list to the 
destination bridee. 


B.U.attach 




Negative response to a 
MAC.enquiry. 


Move the destination bridge 
from the in-range list to the 
out-of-ranee list 


B.A 




MAX_HELLO_LOST 
consecutive HELLO packets 
from the parent node are 
missed. 


Detach. Remove old entries 
from the in-range list; 
initialize the out-of-range list 
to the parent node; set 
MAX_HELLO_PERIOD 
hello-timer. 


B.U.wait 




HELLO packet received from 
parent with an infinite path 

cost 


Detach. Remove parent and 
old entries from the in-range 
list; remove old entries from 
the out-of-range list; set 
HELLO.TIMEOUT HELLO 
timer. 


B.U.wait j 

i 

! 

1 

1 
! 

! 




HELLO packet received with 
new ROOT ID or Root 
Sequence Number and either 
bridge can not be a root 
candidate or packet has a 
higher priority. 


Detach. Update current-root 
Initialize node identifier to all 
l's. Initialize in-range and 
out-ot-range lists to NULL. 


B^.U.wait j 


BR.A 


Lower priority HELLO 
packet received. 


Detach. Initialize in-range 
and out-of-range lists to 
NULL. 


R.A 



Note that a bridge node will never be in an attached HOLD.DOWN state. 
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Detach packet logic 

A parent node generates a DETACH. request packet whenever it is unable to deliver a message 
to a child node. The two possible cases are I > the child is a bridge, or 2) the child is a 
tenninaJ. 

C;ise I - The lost node is a bridge. 

When a parent bridge node is unable to deliver a message to a child bridge node, it must send 
a DETACH.request packet, to the root node, which contains a detached node list thai 
describes the lost subtree. The list contains all nodes in the routing table of the parent for 
which the lost bridge was the first upstream hop. All downstream bridge nodes in the path of 
the DETACH .request packet must adjust their routing tables by deleting entries which match 
those in the detached list. Detached node information is copied into a bridge s 'detached node 
list". 

Case 2 - The lost node is a terminal. 

Since terminals can be mobile they can be lost often and must be notified quickly. When a 
parent node is unable to deliver a message to a terminal, it must generate a DETACRrequest 
packet, with the terminal specified in the associated detached node list, and flood the packet 
throughout the network using the reliable flooding mechanism described above. Any bridge 
node, which receives the DETACRrequest, adds the detached terminal to its internal 
detached node list 

A bridge node in the forward list does not forward an entry in the detached list of a 
DETACRrequest if the DETACH request came from an upstream node, and the upstream 
node is not the first hop in the routing table entry associated with the entry in the detached list. 
A DETACH.request is discarded if the detached list becomes empty. 

Upstream bridges, which only have terminals nodes (i.e. do not have bridge nodes) as 
children, must convert a received DETACH-request to an unscheduled HELLO.response 
packet (without a forward list) and broadcast it immediately. Therefore, lost node information 
is flooded throughout the coverage area of the spanning tree. An awake unattached terminal 
should quickly discover that it has been detached and can then reattach. 

Each entry in a bridge node's detached list is advertised in HELLO response packets for 
MAX_HELLO_ LOST+2 HELLO times or until the bridge determines the terminal has 
reattached. The same entry can not be in a bridge's detached list for a hold-down time after it 
was deleted from the list 

Since a node assumes that it is detached if it does not receive a HELLO, response packet 
from its parent with MAX_HELLO_LOST HELLO time periods and detached node 
information is copied in HELLO .response packet for MAX_HELLO_LOST+2 HELLO time 
periods, a lost node is guaranteed that it will always discover when it becomes unattached 
within MAX_HELLO_LOST*HELLO_PERIOD seconds, in the worst case. 

Unscheduled HELLO.response messages are generated in each bridge node if a new detached 
bridge is discovered and the time until the broadcast of the next scheduled HELLO .response 
packet is greater than HELLO .TRIGGER seconds. 
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Network Routing. 

A routine table is maintained in each bridge node. The routing table has on entry tor each 
known upstream node. (Downstream routing is defined by the structure of the spanning tree.) 



An example routing table is shown below: 



| destination 


por 


first hop 


age 


child 


delivery 


awake begin 


awake end 




t 






tlae 


service 


time 


time 


hexUXOA 


1 


hex 020A 


0 


false 


null 


null 


null 


hex 020 A 


I 


hex 020A 


0 


true 


null 


null 


null 


hexO80B 


1 


hex 080B 


1 


true' 


I 


15320 


15330 



In the example route table above, the bridge has three descendants - 080A, 020 A. and 080B. 
080A and 080B are terminal nodes and 020A is a bridge node. (Note that the node type can 
be determined by the address.) If the first hop field is the same as the destination field, then 
the (optional) child flag field is set to true. The delivery service, awake begin time, and 
awake end time fields only apply to child terminal nodes with a non-zero delivery service 
field. 

To forward an upstream bridging layer packet, a bridge node looks up the entry associated 
with the destination address in the bridge header. If the entry does not exist, the packet is 
discarded. If the entry does exist, the MAC layer destination address is set to the first hop 
address in the route table~ The MAC source address is set to the address of the bridge node. 
(The bridge header addresses remain unchanged.) The packet is passed to the MAC entity on 
the port specified in the table. 

Route table entries are created or updated whenever a downstream unicast DATA, ATTACK 
or ARP packet is received. If an entry does not exist for the bridging layer source address, an 
entry is created with the destination field set to the bridging layer source address. The fields 
in the (old or new) entry for the destination are modified as follows: 1) the first hop field set to 
the MAC layer source address, 2) the port field is set to identify the MAC entity which 
delivered the packet, 3) the age field is set to 0, and 4) if the destination and first hop fields 
are identical, the child flag field is set to true. 

The age field for each entry is incremented at regular intervals. An entry's age field is reset to 
0 whenever a packet is received from the destination associated with the entry. If no packets 
are received from the destination of an entry for ROUTE_TIMEOUT seconds, the entry is 
deleted from the route table. 

Nodes can maintain their path in the network by sending an ATTACRrequest packet to the 
root node once every ATT ACH_TIMEO UT seconds, where ATTACH JTIMEOUT must be 
shorter than ROUTE.TIMEOUT. The ATTACH^equest packet can be piggybacked on a 
higher-layer data packet, if the node is active. 

If a DETACH.request packet is received from an upstream bridge node, then each entry in the 
route table, with a destination field which matches an entry in the packet's detached list, is 
deleted. 

All nodes must maintain a current parent structure. The structure has a network address 
field, a port field, and an age field. The age field is incremented once per HELLO period. If 
the count stored in the age field reaches MAX.HELLCLLOST, the current_parent structure is 
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re-initialized to null values, and the node becomes detached. The age field is reset to 0 
whenever a scheduled or unscheduled HELLO.response packet is received from the node's 
parent. A downstream packets is forwarded by setting the MAC destination address to the 
current_parenLaddress and then passing the packet on the current_parent.port. 

Ail nodes must maintain a current_root structure. The structure has an age field, a 48-bit 
long root ID field, a root alias field and a root sequence field. The structure is initialized to 
;iil 0*s (or null). The structure is checked, and possibly updated, each time a HELLO.response 
packet is received. It a node receives a HELLO.response packet which contains a long ID, 
iilias, or root sequence number which is different than the associated value contained in the 
structure, then the node becomes unattached and loses its network address. The age field in 
the current_rooi structure is incremented periodically. If NETWORKJTIMEOUT minutes 
expire before a node receives a HELLO .response packet from any bridge node, then the 
eurrent_parent structure is re-initialized and the node loses its address. The age field is reset 
to 0 whenever a HELLO.response packet is received from any bridge node and the root node 
hits not changed. 



Address Resolution and Maintenance. 



Reverse Address Resolution Protocol (RARP) protocol. 

An address server in the root node maintains network addressing information in an address 
table, distributes network addresses to requesting nodes, and resolves network addressing 
problems. Each entry in the address table contains a device type field, a network address 
field, a long ID field, an alias field, an in-use field, and an age field. Entries in the table are 
aged so that they can be reused after MAX_ADDRESS_LIFE minutes. Note that entries may 
remain in the table indefinitely. The age field in an entry is reset to 0 whenever a 
RARP.request or ATTACRrequest packet is received from the node associated with the entry. 

A separate sequential set of unique node identifiers is maintained for each device type. Each 
set begins with an identifier of 1 and ends with the maximum range for the device type. 
Lower node identifiers are distributed before higher identifiers* 

A RARP.request packet can be used to: i) acquire a network address from the address server, 
2) change an existing 48-bit long ID in the address table, or 3) change an existing alias in the 
address table. 

A node which does not yet have a unique 16-bit network address must request a 1 1-bit node 
ID from the address server. The node uses a 16 bit multicast address until a unique node ID 
is assigned. The low order 15 bits of the temporary address consist of the node's device type 
concatenated with an 1 1 -bit node ID of all Ts. A RARPxequest packet, containing the 
requesting node's unique 48-bit long ID and/or an alias, is sent to the address server by the 
requesting node. When a node requests a new address, the server first checks its address table 
to determine if the node already has a valid address. If the node doesn't already have an 
address, the server allocates the first available node identifier for the device type, to the node, 
if one is available. In either case, if an address is available, the server will set the network 
address field in the RARP packet to the allocated address and will set the return code bits to 
0. If an address is not available, or an entry already exists in the address table with ambiguous 
identifiers, the address server will set the network address field to all l's and will indicate the 
error in the return code field. 
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The long identifier and/or alias in a RARP.request packet matches an entry in the address 
table I ) if matching 48-bit IDs and aliases are present in both. 2) if both contain a matching 
alias and neither has a 48-bit ID , or 3) if both contain a matching 48-bit ID and neither ha^ an 
alias. If either the 48-bit ID or alias in the request packet is also in the address table, and the 
above criteria are not met, an error is returned. 

Occasionally, a node may want to change the association between a 48-bit ID and an alias. If 
the node simply requests a new address, and its old address has not expired, an error will be 
returned. The requesting node can override the error and force a change by setting the New 
Alias or New Long ID bits in the RARP.request operation field. A change operation causes a 
new address table entry to be created if neither the long ID or alias can be found in the address 
table. 

A requesting node can specify that it does not have a 48-bit ID by not including it as a 
parameter or by including an ID of all O's. An alias is required if there is no 48-bit ID. A 
requesting node can specify that it does not have an alias by not including it as a parameter, or 
by including an alias with a length of 0. 

The address server will return a RARP.request packet to the requesting node as a 
RARP.response packet If the node, which generated the RARP.request packet, does not 
receive a RARP.response packet within BRIDGE_TIMEOUT seconds, it must resend the 
RARP .request. 



RARP hexadecimal 4-bit error codes. . 

0 = good. 

1 = a node ID is not available. 

2 = Duplicate alias. The alias specified in the RARP.request packet is already in the address 
table with a different long ID. 

3 = Duplicate long ID. The long ID specified in the RARPxequest packet is already in the 
address table with a different alias. 

4 = Invalid device type. 
F = Extended error code. 



RARP routing. 

Each bridge node maintains a RARP routing table which contains entries for upstream nodes 
which have recently sent a RARPjequest packet to the root node. 



An example RARP route table is shown below: 



lone ID 


alias 


port 


first hoo 


network address 


return code 


age 
0 


hex 1 003508 A990C 


null 


1 


hex 020A 


hex FFFF 


invalid 


hex 1 003508 A920B 


term2 


1 


hex FFFF 


hex 080C 


0 


3 



Whenever a RARPxequest packet is received, an entry is created (or updated) in the RARP 
route table and the long ID and/or alias fields in the entry are set to the values specified in the 
request packet. The node which initiated the request is defined by the long ID and/or 
alias. The long identifier and/or alias in a RARPxequest packet matches an entry in the RARP 
route table 1) if matching 48-bit IDs and aliases are present in both, 2) if both contain a 
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matching alias and neither has a 48-bit ID , or 3) if both contain a matching 48-bit ID and 
neither has an alias. The return code is initialized to invalid to indicate that an associated 
RARP.response packet, destined for the node which originated the RARP.request has not 
been received. The port field points to the port on which the RARP.request was received. 
The network address is set to the bridging layer source address of the RARP.request packet, 
i Normally, the node ID in the bridging layer source address will be all Is, which is the default 
global node ID used before a unique network node ID is obtained. If a node is attempting to 
change its long ID or alias, then the network address may be unique.) The first hop field will 
be set to the MAC source address. The age field will be set to 0. 

Normally, a bridge node will forward RARP.request packets to the root node on the port 
specified in the current_parent structure. However, if a bridge node receives a RARP.request 
packet, and I) an entry for the node which initiated the request is already in the RARP route 
table, 2) the entry has a return code field which'is valid, and 3) the network address field is not 
all l's, then the bridge can simply return a RARP.response packet to the source node. The 
return code and age fields in the route table entry are not modified. The network address and 
return code fields in the RARP.response packets are set to the values contained in the RARP 
route table. 

When a bridge node receives a RARP.response packet from the root node, it will update the 
return code and network address fields in the RARP route table entry for the node which 
initiated the request. RARP.response packets are forwarded on the port specified in the route 
table entry. The MAC destination address is set to the first hop address, 

RARP route table entries are aged (quickly) so that older entries are discarded in 
RARPJTIMEOUT seconds. 



Address Resolution Protocol (ARP) protocol. 

A node can request the 16-bit network address of another node by sending an ARP.request 
packet to an address server in the root node. The ARP.request packet must contain either the 
48-bit identifier or the alias of the target node, but not both. The address server returns the 16- 
bit network address of the target node in an ARP.response packet, if the target node exists in 
the server's address table. An address of all l's and an error is returned if the target node is not 
in the address table. 



ARP 4-bit hexadecimal error codes. 

0 = good. 

1 =long ID not found. 

2 = alias not found. 

F = extended error code. 
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Address Maintenance. 

A node will lose its address if: 

1 ) The root node changes (i.e. either a different ROOT ID or ROOT ID Sequence Number is 
detected in a HELLO. response packet). 

2) It has not received an ATTACH.response packet from the root node, within an 
ADDRESS JTIMEOUT time period. 

3) No network activity is detected within a NETWORK JTIMEOUT time period. 

The root node can change because 1) the root node is lost or 2) a new root is chosen with the 
root selection protocol. All bridge nodes which detect the change must broadcast 
HELLO.response packets at scheduled times with the new ROOT ID and an infinite path cost 
for MAX.HELLO.LOST+2 HELLO times. If the root node is lost the new ROOT ID will be 
either a 48-bit long identifier of all O's, if the old ROOT ID was a long identifier, or a null 
alias if the old ROOT ID was an alias. If the a new root is chosen the new ROOT ID will be 
either the 48-bit long identifier or alias of the new root node. Note that a new occurrence of 
the same root node can be always be detected because the ROOT ID sequence number will 



A node can maintain its address by sending an ATTACH.request packet to the root node at 
least once per ADDRESS.TIMEOUT time penod. Note that a node must send an 
ATTACRrequest to the root at least once per ROUTE_TIMEOUT time period, to maintain its 
path to the root in the spanning tree; therefore no special logic is required for address 
maintenance. If the node is active it can simply piggyback the ATTACRrequest on a higher- 
layer downstream data packet. The root node will return an ATTACHj-esponse packet and 
the node can reset its ADDR£SS_TIMEOUT timer when the response packet is received. 



HELLO Timing. 

HELLO.response packets can be unscheduled or scheduled. 



Unscheduled HELLO timing. 

Unscheduled HELLO .response packets are broadcast in response to HELLCrequest packets. 

In addition, an unscheduled HELLO .response packet is generated in each bridge node if a new 
detached bridge is discovered and the time until the broadcast of the next scheduled 
HELLO.response packet is greater than HELLO .TRIGGER seconds. 



change. 



NO RAND CONFIDENTIAL 



1 1 £ 




No RAND SST Network 
Brilx;in<; Layer Specification 



Revision K 9/17/92 



P.MiE 26 



Scheduled HELLO timing. 

Each attached bridge node broadcasts one scheduled HELLO.response packet per 
KELLO.PERIOD seconds. Each HELLO_PERIOD time period is divided into 
AVG.HELLO.SLOTS slots, where each slot is HELLOES LOT.SIZE seconds. Initially, a 
hridee node chooses a slot and broadcasts a HELLO.response packet. The HELLO.response 
packet contains a "seed" field which is used in a well-known "hello randomization algorithm" 
to determine the next hello slot and the next seed for the bridge node's next HELLCresponse 
packet. The algorithm guarantees that a bridge node will randomly broadcast its next 
HELLO.response packet within a MIN_HELLO_PERIOD second to M AX _ HELLO _PERIOD 
second time window alter its last HELLO transmission. 

Since significant cumulative delays in hello timing are prohibited, nodes can execute the 
hello randomization algorithm i times to determine the time (and seed) of the i-th successive 
scheduled HELLO response packet from a bridge node. For example, a SLEEPING terminal 
node can initially synchronize on a HELLO.response packet from its parent The terminal can 
calculate the time of a future HELLO response packet from its parent and can power-down 
with an active timer interrupt set to wake it just before the broadcast of the HELLCresponse 
packet is expected. 

Contention delays incurred during the transmission of a HELLO.response packet are recorded 
in a "displacement" field in the packet The displacement field specifies the transmission 
offset time, in hundredths of seconds, from the calculated transmission time. Note that errors, 
caused by rounding to the nearest displacement, can cause some drift in calculated 
transmission times. Therefore, nodes should resynchronize every time a HELLO.response 
packet is broadcast If the displacement field, in a HELLO jesponse packet is set to all l's, 
then the transmission time of the packet does not coincide with a calculated hello time, and 
the packet should not be used for hello synchronization. The displacement is set to all I s in 
unscheduled HELLO.response packets and is set to all l's in scheduled HELLO.response 
packets whenever the packet can not be sent within M AX_HELLO_OFFS ET milliseconds. 

If an expected HELLO .response packet is not received at the calculated time, then the 
receiving node should wait for the maximum displacement time before assuming the HELLO 
packet was missed. The maximum displacement time can be calculated, in milliseconds, by 
multiplying the number of hello periods, since the last HELLO packet was received, by 
MAX_HELLO_OFFSET. 

Note that HELLO slot boundaries for different bridge nodes are not necessarily aligned (i.e. 
as in slotted ALOHA). In fact to increase randomization, bridge nodes should avoid slot 
alignment A "HELLO slot" is simply the unit of time used in the randomization algorithm. 

Default HELLO_PERIOD and HELLO_SLOT_S IZE values are set at compile time and are 
well-known by all nodes. Modified HELLO.PERIOD and HELLO_SLOT_SIZE values can 
be set by the root node and advertised throughout the network in HELLO.response packets. 
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The algoriibm used for HELLO time calculation is defined by the "C* routines below. The 
routines assume that lastjiellojime and lastjiellojeed variables are maintained for each 
bridge node of interest A bridge node should set the last Jiello jime variable, associated with 
its HELLO.response packet broadcasts, to the last HELLO transmission time, adjusted to 
account for any displacement. For example, if a bridge node's HELLO transmission time is 
delayed approximately 20 milliseconds, then it should set the displacement field in the packet 
to 2 and sets its lastjiellojime variable to the transmission time minus 20 milliseconds. 

Two routines are shown below: 

setjast.hello - is used to extract lastjiellojime and lastjiellojeed from a received 
HELLO, response packet. The last_heilo_time variable is adjusted to account for the 
displacement field. The routine assumes that packets are accurately time-stamped (i.e. by the 
MAC layer) when they are received. 

calc_next_hello - is used to calculate the time and seed of the next HELLO.response packet 
for the bridge specified by the address passed to the routine. 

The routines rely on the address table functions - Insert and Lookup. Insert enters an address 
into a table, if it does not exist and returns the index. Lookup returns the index of an address, 
if it exists. 

int set_last_hello_time(PACKET * heilo_packet) 



offset=faeUo_packet->hello_seed & B.MASK.DISP; 
if (offset=BJ4ASKJMSP) 
return -1; /•* next hello time cannot be calculated, if the displacement is all l*s */ 

/* else, determine the seed and hello time */ 
i=lnsert(hello_packet->mac_s_addr); 

Uist_hello_time[i]=heilo_packet->receive_time - ((TIMEXoffset)); 
last_hello_seed[i]=hello_packet->hello_seed » 2; 
return 0; 

} 

int calc_next_bello(int address, TIME* next_time, int* next seed) 
{ 

int next_slot; 
i=Lookup(address); 

if (i < 0) return -1; /* next hello time cannot be calculated */ 

*nexctime=alasLhello_time[t]; 
*next_seed=lasUiello_seed[i]; 
while (*next_time <= current_time()) 

{ 

next_slot=((*next_seed+address) % HELLO_MOD_VAL) + HELLO_MOD_ V AL; 
*next_time += next.slot * HELLO_SLOT_SIZE; 
*next_seed=((seed + 3) A 0x2 A) & 0x3 F; 

\ 



return 0; 
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Sleeping terminal support 

The bridging layer provides a service which will store pending messages for SLEEPING 
terminals. Terminals request the service by setting the optional "delivery service" parameter 
< type hexadecimal OE), in the optional parameter area in any bridging layer packet. If a child 
node does not set the parameter or sets it to 0 (the default value), then the parent bridge node 
will attempt to deliver packets to the child node immediately. The child node is assumed to 
be lost whenever a packet can not be delivered. If the parameter is set to 1, the source child 
node is assumed to be a SLEEPING terminal and the parent node will not attempt to deliver 
packets to the child node until the child notifies the parent that it is awake. If the parameter is 
set to 2, the parent bridge will attempt to deliver packets immediately, with a reduced retry 
count; if a packet can not be delivered, the parent will store the packet until the child node 
notifies the parent that it is awake (or a save time expires). 

A child node can notify its parent node that it will be awake by setting an optional "awake 
time'* parameter (type hexadecimal OC) in any bridging layer packet. The awake time is 
specified in AWAKE_TIME_UNIT time units. A value of all l's indicates forever. By 
default, the awake time period is assumed to follow the end of transmission of the packet 
containing the awake time parameter. Optionally, an offset can be specified with the optional 
"awake time offset" parameter (type hexadecimal OD). The awake time offset parameter 
specifies an offset time at which time the terminal will wake up and stay awake for the time 
specified in the associated awake parameter. The offset is specified in AW AKE jnME_UNIT 
time units and is added to the end-of-transmission time. This option allows a terminal to 
initiate a transaction, sleep for a statistically calculated time period, and then wake up to 
accept a response. 

If a bridge node determines that a SLEEPING terminal is sleeping then it will store packets 
destined for the terminal for a number of HELLO periods, or until delivery to the child node is 
attempted. The number of HELLO periods that a packet will be saved is set to 
DEF_S A VE_CNT, by default and can be set from 0 to MAX_SAVE_CNT by a child node 
with the optional "store message count" parameter (type hexadecimal OF). Whenever a bridge 
node is storing a message for a terminal, the terminal's address will be included in the 
"pending message list" in successive HELLOxesponse packets broadcast by the bridge node. 
If the message can not be delivered within "store message count" HELLO periods then the 
bridge node will assume that the child terminal node is lost. 

As an example, a SLEEPING terminal might notify its parent that it will be awake, in a time 
window when a reply message (Le. from a host computer) is expected, by setting the awake 
time and awake time offset parameters in the packet which solicited the reply. If the reply 
message is not received when expected, the terminal can alternate between sleep periods and 
short awake time periods. An empty DATA.request packet containing a "wake time" 
parameter can be used to notify the parent of successive wake time periods. (Note that a 
parent node will generate an ATTACRrequest packet with the ATTI bit set ON whenever a 
DATA.request packet is received from a terminal and a routing table entry does not exist for 
the terminal. Therefore, the empty DATA.request also ensures that the node is still attached 
to the network.) Whenever a SLEEPING terminal expects a reply message the terminal 
should wake up to receive all HELLO.response packets from its parent If an expected 
message is not received during any of the awake periods, the terminal can simply continue to 
listen to scheduled HELLO.response packets. If a response message is expected and a 
threshold number (i.e. 1 or 2) of consecutive HELLO.response messages are missed, then the 
terminal should transmit a (empty) DATA.request packet to its parent to determine if it is still 
in range. Note that if the parent bridge fails to deliver a message to a child terminal then 
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either 1 ) the child will see its address in a "detached node list", or 2) will reattach to the 
network after a threshold number of HELLO.response messages are missed. 

LLC implementation notes: 

An LLC layer RR (receive-ready) packet, with the final bit set ON, should be transmitted by 
the terminal whenever the terminal attaches to the network. This ensures that higher layer 
data which may have been lost will be retransmitted immediately by the LLC entity at the 
remote end of the LLC connection. 

Receive timeouts can be handled by the LLC entity in a terminal, if the bridging layer 

1 ) allows the LLC layer to pass an awake time window along with a data message. 

2) provides a M request_message" service to thelLC layer. The request.message service 
causes the bridging layer to send an "awake__time M packet to the parent bridge node. 

3) notifies the LLC layer whenever the terminal ( reattaches to the network. 

4) provides a "net_monitor" service to the LLC layer. The net.monitor service causes the 
network layer to wake up for all HELLO packets from the parent bridge node, and causes the 
network layer to query the parent node (with an empty DATA.request packet) when a HELLO 
packet is missed. 
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An example algorithm for sending a message, for which a reply message is expected, using 
type I delivery service, is shown below: 

awake_time_windowobegin=minimum_data_deiay; 

aw;ike_time_window->end=calculated_data_delay; 

set_;tfann(SHORT_TTMEOUT, 

awake.time^windowobegin+awake.time.window-^nd+pausetO)); 
set_alajm( LLC.TIMEOUT, MAX_LLC_TIMEOUD; 
net_send(destination. LLC.data. awake_time_window);* 
net_tnonitor(TRUE); 

while (waiting_for response) 

{ 

event=wait(event_Q); 

if (event=SHORT_TIMEOUT && request_count++ < AWAKE.M AX) 

I 

request_message(awake_time); 
set_alarm(SHORT_TIMEOUT ( pause(request__count)); 

} 

else if (even t= REATTACH) 

{ 

awake_time_window->begin=0; 
awake_time_window->end=RJ*jnMEOUT; 
request_count=AWAKE_MAX; 
reset_alann(LLCjnMEOUT, RR_TIMEOUT); 
net_send(destination, LLC_RR, awake.time window); 
} . . 

else if (event=LLC_TTMEOUT && retry count++ < LLC.MAX) 

{ 

awake_time_window->begin=sO; 
awake_time_window->end=RR_TIMEOUT; 
request_coum=:AWAKE_MAX; 
reset.alarmaLC.TIMEOUT, RR.TIMEOUD; 
net_send(destination, LLC.RR, awake.time window); 

} 

else 

waiting_for_responsesFALSE; 

} 

net_monitor(FALSE); 
set.alann.offCSHORT.TIMEOUT); 
set.alarm_off(LLC.TIMEOUT); 
return event; 

The while loop will terminate if 1) a reply message is received* 2) the maximum number of 
LLC timeouts is exceeded, or 3) a RR/RNR frame is received from the remote LLC entity. In 
the last case, the LLC state machine will either determine that the original LLC data frame 
must be retransmitted or that the LLC entity should continue to wait for a reply message. 

*Note that the FINAL bit should be set OFF in the "LLC.data" frame so that an unnecessary 
RR frame will not be generated by the remote LLC entity. 
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Introduction. 

This document in conjunction with the SST network frame format specification, defines the hop-to-hop 
link protocol used on RS485 LAN links, spread spectrum radio links and ethernet links. 

Functional Requirements and Capabilities. 

The MAC layer 

- accepts frames from the bridging layer and passes frames to the physical layer for transmission. 

- spends MAC layer framing bytes and CCITT- 16 FCS bytes to transmitted frames. 

- removes MAC layer framing bytes and FCS bytes from received frames. 

- verifies the FCS bytes in received frames. 

- filters out frames which do not belong to the SST network of the local device. 

- filters out packets which are not directed to the local device. 

- forwards packets to the bridging layer which are directly addressed to the local device, or are broadcast 
or multicast to the local device. 

- regulates access to the communications channel on RS48S links and spread spectrum radio links. 

- schedules lost un teas t frames for retransmission. 

- detects and discards duplicate back-to-back unicast MAC level data frames. 
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- provides device-to-device flow control. 

- transparently fragments and reassembles bridging layer packets, which exceed the maximum MAC 
frame size. 

- maintains and provides diagnostic statistics tor higher layers. 

Terminology and Definitions, 
frame - MAC layer protocol data unit, 
packet - bridge layer protocol data unit. 

A channel access algorithm is used to regulate access to a communications channel. The 
implementation of a channel access algorithm is dependent on the link type: 

A p-persistent CSMA/CA (carrier sense multiple access with collision avoidance) protocol is used to 
eain access to an RS485 LAN. The collision avoidance scheme gives channel access priority to the 
recipient of a unicast frame. 

On lightly loaded spread spectrum radio links, a non-persistent CSMA algorithm is used to gain access 
to the communications channel. 

On moderately to heavily loaded spread spectrum radio links, an LBT/BP (listen-before-talk with busy 
pulse) algorithm is used to gain access to the channel and minimize the effect of hidden nodes. 

A polling protocol is used to restrict contention to request-for-poll (RFP) frames, thus minimizing 
contention for data frames. 

A CSMA slot is defined as follows: Assume that station A has determined that the channel is idle at time 
0 iind immediately initiates a transmission. Then a CSMA slot is equal to the worst-case time, t t at 
which another station, B, is able to determine that the transmission from A is in progress. The actual 
components of the CSMA slot time are <busy sense time> + turnaround time> + <processing delays 
where each of the components represents a worst-case value. The busy sense time is the time required to 
detect a frame in progress. The turnaround time is the time required by a half-duplex transceiver to 
switch from a receive state to a transmit state. The processing delay includes the hardware/software 
processing time required to initiate a transmission and MAC frame processing time. 

An LBT slot is defined as the total time required to transmit an RFP frame plus the time required by the 
receiver to begin transmitting the response. 

A CA (collision avoidance) sequence of frames consists of one or more frames which are sent following 
a single execution of the channel access algorithm. 

An Interframe gap is defined as the minimum idle time allowed between frames which are considered as 
a single C A sequence. 

An interpoll gap is defined as the maximum time allowed between poll frames which belong to a single 
CA sequence. 

A return priority mechanism allows frames which are transmitted between a pair of nodes to be 
grouped into a single CA sequence which is initiated with one execution of the channel access algorithm. 
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CSMA idle time is the minimum time that a potential transmitter must sense an idle channel before 
assuming the channel is idle. The CSMA idle time is greater than the interframe gap plus the CSMA slot 



size. 



LBT idle time is the minimum time that a potential transmitter must sense an idle radio channel with 
hidden nodes before assuming the channel is idle. The LBT idle time is greater than the interpoll gap 
time plus the CSMA slot size. 

A bracket of frames is defined as a group of one or more MAC -lev el frames which are associated with a 
Miigle bridging layer unit of data. 

MAC-level frames are categorized as either request or poll frames: 

A DATA frame is a MAC-level request frame which is used to send higher-layer data to a receiver. 

An EOD (end-of-data) frame is a MAC-level request frame which is sent as the last data to™ in a 
bracket of one or more data frames. Note that a bracket of data frames may consist of a single EOD 
frame. 

An RFP (request-for.poll) frame is a MAC-level request frame which is used to request polling from a 
receiver and to determine the SEQ state of the receiver. 

An ENQ (enquiry) frame is a MAC-level request frame which is used to determine the SEQ state of a 
receiver and to determine if a node is within range. 

A POLL frame is a MAC-level poll frame which is used to obtain a data frame from another node and to 
return the current SEQ state. 

A WFP (wait-for-poll) frame is a MAC-level poll frame which is used to inform a requesting node that 
it is scheduled to be polled later and to return the current SEQ state. 

A CLEAR frame is a MAC-level poll frame which is used to inform all listening nodes that the last 
frame in a bracket of frames has been received and to return a defined SEQ state. 

A REJECT frame is a MAC-level poll frame which is used to return an undefined SEQ suite or to 
indicate that a received request frame was invalid. 



MAC control byte bit definitions. 



Request or poll frame control byte bit definitions. 
R/P (request/poll) bit 

The R/P bit is used to distinguish MAC layer request and poll frames. If me R/P bit is set OFF the frame 
is a request frame. If the R/P bit is set ON the frame is a poll frame. 

SEQ bit 

The SEO bit is used to sequence MAC layer data frames, modula 2. The SEQ field is used to detect md 
^S^iS^ A state machine which illustrates the use of the SEQ bit and the response m « 
bit is shown below. 
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LAN ID bits. 



The MAC frame belongs to the spanning tree specified by the LAN ID bits. The MAC entity discards 
frames which belong to spanning trees which are not in its LANJDJist Note that LAN JD .list is a 
parameter of the MAC .enable call. 



Request control byte bit definitions. 

DATA bit. 

The DATA bit is used to distinguish control request frames from data request frames. 
MORE bit 

In control request frames the MORE bit is used to distinguish RFP frames from ENQ frames. 

In data request frames, the MORE bit is used to distinguish between DATA frames and EOD frames. 
The last frame sent in a bracket of data frames is always an EOD frame. 

PRIORITY bit 

The PRIORITY bit indicates the priority of a higher layer message and is set as specified by the bridging 
layer, in the MAC send call: The receiver simply passes the priority to the bridging layer. The 
PRIORITY bit value is the same for all frames which are associated with a bracket of frames 



Poll control byte bit definitions. 
MORE bit 

The MORE bit is used to distinguish POLL frames from CLEAR frames.* 
WAIT bit 

The WAIT bit is used to distinguish POLL frames from WFP frames.* The receiver of a request frame 
™ return a poll frame with the WAIT bit set ON in the associated poll frame to put die requesting node 
in a quiet state for WFP TIMEOUT seconds. The requesting node must refrain from transmuting 
unicast frames to the receiver until the quiet period expires or a POLL frame is received from the 
receiver. 

* A REJECT frame is specified by setting the MORE bit OFF and the WATT bit ON. 
Bridging Layer Interface Specification. 

Each node in the network has a single bridging entity which invokes a MAC entity per port to send and 
receive messages on the port. 

MAC layer services are provided with the following routines: 
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MAC_enable<port, LANJDJist) 
\lAC_set_address(port, net_address) 

\IAC_send(port dest.net.address, buffer control .flags, [mailbox], [queue]) 



hit 7 


priority 


0 = normal. 1 = high 


hit 6 


reserved 


must be zero 


hit5 


reserved 


must be zero 


hit 4 


reserved 


must be zero 


hit 3 


p flats 


1 = p-persistent 


bit 2 


reserved 


must be zero 


bit 1-0 


LAN ID 


(spanning tree ID) 



length=MAC_accept(port, buffer, wait) 

MAC_stop(port) 

MAC_start(port) 

MAC_dlsable<port) 

MAC_enquiry(port, dest_net_address) 

MAC_dlagnostlc(port, .'. .) 

Initially, the MAC entity attached to a port is in a DISABLED/OFF state. The bridging layer enables a 
MAC entity on a port by calling MAC_enable(port LANJDJist). where LANJDJist defines the 
spanning trees to which the node can belong. MAC.enable changes the MAC entity state to 
ENABLED/ON. 

The MAC entity uses a default multicast address consisting of the node type and a node identifier ot all 
I s, until the bridging layer assigns a specific network address to the MAC entity. The MAC_set_address 
call is provided for this purpose. 

The bridging layer accepts messages from the MAC entity by issuing a MAC.accept call. The returned 
buffer includes the MAC header, but does not including media framing and CRC characters. The wiut 
parameter can be used to suspend the caller for some length of time or until a message is received. The 
MAC entity must be capable of queueing messages until they are accepted by the bridging layer. 

The bridging layer requests the MAC entity to transmit a bridging layer packet by issuing a call to 
MAC.send. Packets are grouped into a set of one or more MAC layer frames which, together, consume 
a bracket. On radio ports, if the size of a bridging layer packet exceeds the maximum MAC frame 
length, then the packet is fragmented. A bracket normally contains a single data (EOD) trame on wired 
links. The MAC entity prefixes a MAC header to the beginning of each frame in a bracket before 
transmitting each frame. The MAC layer is also responsible for providing media framing, which includes 
a link-type-dependent synchronization preamble, start-of- frame delimiter, end-of-frame delimiter, and 
CRC-CCITT frame check sequence bytes for each frame. The control.flajjs parameter in the 
MAC.send call is used to 1) set the priority bit in the MAC header (priority). 2) to indicate if the butter 
is being sent in response to a multicast bridging layer packet (p.flag). and 3) to set the LAN ID held in 
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the MAC header. The optional mailbox and queue parameters are mutually exclusive and are used tor 
asynchronous calls. 

The maximum size of a buffer passed to the MAC layer tor transmission is MAX.PKT_SIZE. 

The hndaine laver am disable the MAC receiver by calling MAC.stop. The MAC entity is in an 
ENABLED/OFF state alter a call to MAC.stop is issued. The bridging layer forces the MAC enuty back 
into the ENABLED/ON state by calling MAC.send or MAC.stan. 

The bridging layer can disable the MAC entity and force it to the DISABLED/OFF state by calling 
MAC.disable. 

MAC_enquiry can be use to determine if a destination node is within range. 
MAC.diagnostic is used to retrieve diagnostic statistics from the MAC layer. 

Link Interface Specification. 



Frame/packet filtering. 

When the MAC enuty is in an ENABLED/ON state it is continuously listening on itsassigned port. The 
MAC entity receives all MAC layer frames. Frames which do not pass a CRC-CCITT check are uvalid 
and are discarded. Valid data frames are reassembled into a complete packet which ts posted to the 
bridging entity if: 

1) The LAN ID in the MAC header is among those contained in the LAN ID list passed to the MAC 
entity in the MAC_enable call, and 

2) The destination address in the MAC header a) is equal to the network address of the local node, or b) is 
an acceptable multicast or broadcast address. 

The high-order multicast bit is set ON in all multicast or broadcast frames. A multicast or broadcast 
frame is accepted if the node type specifies a group to which the local node belongs and either a) the 
node identifer is all I s, or b) the node identifer is equal to the identifier of the local node. A response is 
never required when the multicast bit is set ON. 

The default network address used when the MAC entity is first enabled consists of the multicast node 
type concatenated with a node identifier of all l's. For example, the default address for a bridge is 
beVidecimal A7FF. The bridging layer is responsible for obtaining a network address and assigning it to 
the MAC entity on the pore 

Channel access. 

A return priority mechanism is used to group MAC layer request and poll frames into a single CA 
seiueTce Tchannel access algorithm is executed to gain access to the channel before the tirst trame ,n 
a C A sequence is transmitted. All other frames in a CA sequence may be sent without executing the 
channel access algorithm. The idle time between frames which belong to a single CA sequence must be 
less than the maximum Interf rame gap time. 
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On wired links, the CSMA/CA algorithm forces nodes to detect an idle channel for a CSMA idle time 
which exceeds the interframe gap time before initiating a CA sequence. 

On radio links "hidden nodes" can cause throughput to be significandy degraded on spread spectrum 
radio links. Under lightly loaded conditions, a CSMA channel access algorithm allows nodes to access 
the radio channel immediately after detecting an idle channel. Under moderate to heavily loaded 
conditions, the LBT/BP algorithm forces nodes to detect an idle radio channel for an LBT idle time 
which exceeds the Interpol! gap time, before accessing the channel. By listening for longer than the 
interpoll gap time, a node will detect a conversation in progress, if both involved nodes are in range or 
onlv one node is in range and the other node is hidden. Limiting the time between frames in a CA 
sequence to a short fixed interval, essentially provides a busy-pulse signal which spans the coverage area 
of both nodes involved in a conversation. 

A CA sequence of frames begins with the transmission of a request or poll frame, following an execution 
of the channel access algorithm. Possible successive frames in a CA sequence are: 

1) Any poll frame sent in response to a unicast request frame. 

2) A DATA or EOD frame sent in response to a POLL frame. (UmnF . p 

3) A bridge node can "piggyback" a second frame onto a transmitted broadcast, multicast, WFP. CLEAR, 
or REJECT frame, by transmitting the second frame within the interframe gap time. 



Message Bracketing. 

The size of packets which are passed to the MAC layer by the bridging layer must be less than, or equal 
to. MAX.PKT.SIZE, where MAX.PKT.SIZE specifies the total length of the packet, including bridging 
and data-link header characters. 

Packets which are larger than MAX.FRAME.SIZE must be fragmented, by the MAC entity, to insure 
that the interpoll gap time is constant The fragmented frames are transmitted as a bracket with the 
MORE bit set OFF in the last frame to mark the end of the bracket Frames which belong to a single 
bracket are reassembled by the MAC entity in the receiver before the packet is posted to the bridging 
la^er in the receiver. If the entire bracket is not received successfully, then all other frames in the bracket 
are discarded by the receiver. Note that the maximum number of data frames in a bracket is the ceiling 
of MAX.PKT.SIZE / MAX_FRAME_SIZE. 

MAX FRAME.SIZE does not include characters added at the MAC level. MAX.FRAME.SIZE on the 
192K bps spread spectrum radio link is limited by the interpoll gap time. 

On a wired links with low error rates, MAX.FRAME.SIZE is set so that a bracket is generally limited to 
a single EOD frame. 

A bracket of frames may be transmitted in one or more CA sequences, where a channel access algorithm 
is used to gain access to the link for each CA sequence. A transmitter initiates the transmission ot a 
bracket of frames by sending either an RFP frame or an EOD frame to a receiver If a receiver is not 
buy the receiver will respond to RFP and DATA frames with a POLL frame, winch solicits the : next 
DATA frame and implicidy acknowledges the previous frame. A receiver responds to an EOD frame 
with a CLEAR frame If a receiver is busy or does not have a buffer, then the receiver may respond to 
RFP. DATA or EOD frames with a WFP frame. 
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Example transmit/receive sequences. 

The following sequences illustrate typical transmission sequences, in the absence of errors, for sending a 
bracket of data frames from a transmitter to a receiver. 



Sequence 1: 
RFP 

< — 

EOD — 



POLL 



CLEAR 



CLEAR 



Sequence 2: 

EOD 

< 

Sequence 3: 

RFP > 

< POLL 

DATA > 



EOD 



<— 
<— 

Sequence 4: 



----- POLL 
— > 

----- CLEAR 



RFP 



DATA 



<-- 



(pause) 



< 



WFP 
POLL 



< — 



EOD 



POLL 



CLEAR 



Sequence 5: 
ENQ — - 



<-- 



CLEAR 



Sequences 3 through 4 can only occur on radio links. Note that, in sequence 2. an EOD frame : is sent 
immediately, without sending a prior RFP frame. It is possible to skip the transmission of an RFP tranu- 
if the transmitter "remembers" the SEQ state of the receiver. This facility is limited to the transmission 
of short EOD frames on wired links. Sequence 5 can be used to determine the SEQ state of a receiver , r 
to determine if a node is within range. 
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Recovery, 

The node which initiates a bracket of frames u.e. the transmitter) is responsible for recovery until the first 
POLL frame is received. 

The receiver is responsible for polling the transmitter as soon as an RFP frame is received and assumes 
responsibility for recovery at that point. 

It is possible for both the transmitter and receiver to be in contention to recover a lost frame (i.e. RFP or 
DATA) if the first POLL frame is lost. The contention is resolved with a random backoff algorithm. 

If a CLEAR frame is lost and the polling node which sent the CLEAR frame is responsible for recovery, 
then the requesting node which initiated the bracket can not determine if the link was lost or the CLEAR 
frame was lost. The requesting node must send an ENQ frame to determine which case holds. 

Transmit and Receive State Machine (SM) Specifications. 

No state machine is required for multicast and broadcast frames. Multicast and broadcast frames can be 
transmitted whenever the channel is available. Received multicast or broadcast frames are simply 
discarded or posted to the bridging layer. 

State Machines for Bracket Transmission. 
Bracket Transmit State Machine. 

State descriptions: 

[DLE - The suite machine is idle and is waiting for a bracket of frames to transmit. 

READY - The state machine has a bracket of 1 or more frames to transmit and is waiting to acquire the 
channel.* 

S_RFP - The state machine has sent an RFP frame and is waiting for a POLL frame. 

S_DATA - The state machine has sent a DATA frame and is waiting for a POLL frame. 

S.EOD - The state machine has sent an EOD frame after receiving a POLL frame and is waiting for a 
CLEAR frame. 

RDY_WATT - The state machine has received a WFP frame and is waiting for a POLL frame (or 
timeout). 

The following states only apply to transmissions on a wired link which are not initiated with a request to 
polling. 

READY2 - The state machine has a single short frame to transmit, is waiting to acquire a wired link, ;uu 
the SEQ state of the receiver is known. 

S_EOD 2 - The state machine has sent an unsolicited EOD frame is waiting for a CLEAR frame. 



NORAND CONFIDENTIAL 



131 




Nora no SST Network 

MAC Layer Protocol Specification 



Revision I. 2/17/92 



paoe II 



* There is an automatic and immediate transition from the READY state to the READY2 state if all of 
the following conditions are true: 1 ) the communciations channel is a wired link,' 2) the SEQ state of the 
receiver is known, and 3) the bracket to transmit consists of a single EOD frame which is less than 
MAX_SHORT.FRAME.SIZE in length. 



A RSP.TIMEOUT receive timer is started when a) an RFP frame is transmitted, 2) an ENQ frame is 
transmitted, and 3) on wired links, when an EOD frame is sent without first sending an RFP frame. The 
timeout value is larger than interframe gap time plus the time required to transmit a POLL or CLEAR 
frame. If the RSpJtIMEOUT timer expires before an expected response is received, a retry counter is 
incremented and the request frame is retransmitted, if the retry count has not been exceeded. 

A POLL.TIMEOUT receive timer is started whenever a DATA or EOD frame is transmitted following 
an RFP frame. The timeout value is larger than the time required for the maximum number of poll retry 
attempts. The MAC layer returns an error to the bridging layer if this timer expires before an expected 
poll frame is received. Note that the receiver is responsible for recovery when this timer is running. 

A WFPJTTMEOUT timer is started whenever a WFP frame is received. The RDY_WAIT state ends 
when this timer expires or a POLL frame is received. 

The state machine must maintain a "current pointer" variable which points to the current frame, in a 
bracket of frames, to be transmitted. The current pointer is advanced if t and only if, a POLL for the next 
frame in the bracket is received. If more than one transition is specified when a POLL frame is received, 
the state of the current pointer determines which transition should be taken. 

Retransmission logic and SEQ state maintainence are specified in the section which describes suite 
machines for frame SEQ control. 

The first state table below specifies transitions for bracket transmissions which are initiated with a polling 
request. The second table specifies transitions for non-polled frame transmission (i.e. a single short EOD 
frame on a wired link). Note that there are transitions between the tables. 



Timers: 
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state 


event 


action 


next state i 


IDLE 


A bracket of frames is passed to 
the state machine 


Reset retry count: execute 
channel access algorithm 


READY 


READY 


Channel acquired 


Increment retry count: send RFP 
trame; start RSPJTIMEOUT 
receive timer 


S.RFP 


S.RFP 


RSPJTIMEOUT timer expires 
;ind max. retrv count exceeded 


Return error 


IDLE 




RSPJTIMEOUT timer expires 


Execute channel access 
algorithm 


READY 




POLL received 


Send current DATA frame; start 
POLLJTIMEOUT receive timer 


S.DATA 




POLL received 


Send current EOD frame; start 
POLL TIMEOUT receive timer 


S_EOD 




WFP received 


Start WFPJTIMEOUT timer 


RDY.WAIT 


S DATA 


POLLJTIMEOUT timer expires 


Return error 


IDLE 




POLL received 


Advance current pointer if 
frame was accepted; send 
current DATA frame; start 
POLLJTIMEOUT receive timer 


SJ3ATA 




POLL received 


Advance current pointer if 
frame was accepted; reset retry 
count; send current EOD frame; 
start POLLJTIMEOUT receive 
timer 


S.EOD 


S.EOD 


POLLJTIMEOUT timer expires 


Reset retry count; execute 
channel access algorithm 


RDYJENQ 




POLL received 


Retransmit EOD frame; start 
POLLJTIMEOUT receive timer 


S.EOD 




CLEAR received; EOD frame 
not accepted 


Return error (invalid transition) 


IDLE 




CLEAR received; EOD frame 
accepted 


Return good 


IDLE 


RDY.ENQ 


Channel acquired 


Increment retry count; send 
ENQ; start RSPJTIMEOUT 
timer 


S.ENQ 


S.ENQ 


RSPJTIMEOUT timer expires 
and max. retry count exceeded 


Return error 


IDLE 




RSPJTIMEOUT timer expires 


Execute channel access 
algorithm 


RDY.ENQ 




CLEAR received; EOD frame 
not accepted 


Return error (invalid transition) 


IDLE 




CLEAR received; EOD frame 
accepted 


Return good 


IDLE 


RDY WAIT 


WFP received 


Reset WFP TIMEOUT timer 


RDY^WAIT 




POLL received 


Send current DATA frame; start 
POLLJTIMEOUT timer 


S_DATA 




POLL received 


Send current EOD frame; start 
POLLJTIMEOUT timer 


S.EOD 




WFPJTTMEOUT timer expires 


Reset retry count; execute 
channel acess algorithm 


READY 
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1 

1 .state 


event 


action 


next suite 


READY 7 


Channel acquired 


Increment retry count; send 
EOD frame with RESET on; 
start RSP_TIMEOUT receive 
timer 


S_EOD2 


S_EOD*> 


RSP.TIMEOUT timer expires 
and max. retrv count exceeded 


Return error 


IDLE 




RSP_TIMEOUT timer expires - 


Execute channel access 
algorithm 


READY? 




VVFP received 


Stan WFPJT1MEOUT timer 


RDYJWAIT 




CLEAR received; EOD frame 
not accepted 1 


Return error (invalid transition) 


IDLE 




CLEAR received; EOD frame 
accepted 


Return good 


IDLE 



Bracket Receive State Machine. 



The receive state machine assumes that invalid frames and frames not directed to the local node are 
discarded and do not affect state transitions. Multicast and broadcast frames are simply posted to the 
bridging entity, if a buffer is available, and do not affect state transitions. 

State descriptions: 

IDLE_LISTEN - The receiver is not receiving a bracket of frames. 

BUSY - The receiver has sent a POLL frame and is waiting for the next frame in a bracket. 

BUSY_WAIT - The receiver is waiting for a buffer to become free. 

Tuners: 

A RSP_TIMEOUT receive timer is started when a POLL frame is transmitted. The timeout value is 
larger than interframe gap time plus the time required to transmit a DATA frame. If the RSP.TIMEOUT 
timer expires before an expected response is received, a retry counter is incremented and the POLL frame 
is retransmitted, if the retry count has not been exceeded. 

The receiver must maintain a polLqueue which is a FIFO list of all terminals which have requested 
polling. (Note that a separate queue can be used for high priority requests.) Entries in the queue are aged 
so that they are discarded after WFPJTTMEOUT seconds. The entry at the front of the queue is 
considered active; all other entries in the queue are denoted as queued. Nodes which are not active or 
queued are denoted as Inactive. Note that there is no active node in the IDLE.LISTEN state. 

A SEQ state variable is cached for all nodes which have recently transmitted valid data frames. The SEQ 
state variable is updated as specified in the section which describes state machines for frame SEQcontrol. 

Only one bracket may be in progress at a time. The receiver must reserve enough buffers for an entire 
bracket of frames before sending a POLL frame in response to an RFP frame. This ensures that the entire 
bracket will be accepted. 

"Flush" deletes the entry for a node from the polLqueue, if it exists, and frees any buffers allocated to 
frames received from the node. 
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ll state 


event 


action 




IDLE.LISTEN 


RFP received; buffers 


Send POLL; insert node in 
poll_queue; reset retry count; 
stan RSP_TIMEOUT timer 


BUSY 




tvTr rcccivcu* uuiicrynui 

available 


Send WFP; insert node in 
poll_queue 


DubY_WAJT 




EOD received; buffer 


Send CLEAR; post complete 
packet (if accepted); flush 


IDLEJJSTEN 




EOD received; buffer not 
available 


Send WFP; insert node in 
polLqueue 


BUSY.WA1T 




cixi^ received, entry ror 

^i^nrPA mvfA ic in rhA ^Pf^ 
oUUJLC I1UUC lo III LUC 

state table 


oena LLtAX 


IDLE_LISTEN 




FrVO rPfAivAfi* nit pnrrv fur 

source node in the SEQ state 
table 




IDLE_LISTEN 




DATA received 


Send REJECT 


IDLE LISTEN 


BUSY 


max. retries exceeded 


Flush; delete SEQ state table 
entry 


IDLE.LISTEN 




receive timeout 


Increment retry count; 
execute channel access 
algorithm; acquire channel; 
resend POLL; stan 

R^P TTMFnilT rimpr 

ixjr^ i iivLCvju i inner 


BUSY 




DATA received from active 


Reset retry count; send next 

fVLL, SuUT Kjr_ I IVrlCXJiJ 1 

timer 


BUSY 

j 




DATA received from inactive 
or queued node 


Send REJECT 


BUSY ! 

! 




EOD received from active 
node; no queued nodes 


Send CLEAR; reassemble and 
post complete packet; flush 


IDLE.LISTEN j 




EOD received from active 
node; 1 or more queued nodes 


Send CLEAR; reassemble 
and post complete packet; 
flush; reset retry count; send 
rULL to node at tront or 
polLqueue; stan 
RSP TIMEOUT timer 


BUSY j 

i 




cuu received uum inactive 
or queued node; buffer 
available 


Send CLEAR; post complete 
packet (if accepted); flush 


BUSY 




EOD received from inactive 
or qucuco nooe, ouiier not 
available 


Send WFP; insert node in 
polLqueue 


BUSY 




ENQ received from inactive 
or queued node; entry for 
source node is in the SEQ 
state table 


Send CLEAR; flush 


BUSY 




ENQ received from inactive 
node or queued node; no entry 
for source node in the SEQ 
state table 


Send REJECT; flush 


BUSY 
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ENQ received from active 
node; no queued nodes 


Send REJECT ; flush; delete 
SEO state table entrv 


IDLE.LISTEN 




ENQ received from active 
node; I or more queued nodes 


Send REJECT; flush; delete 
SEQ state table entry; reset 
retry count; send POLL to 
node at head of polLqueue; 
stan RSP_TIMEOUT timer 


BUSY 




RFP received from inactive 
or queued node 


Send WFP; insert node in 
polLqueue 


BUSY 




RFP received from active 
node 


Send WFP if polLqueue is 
not empty; flush; insert node 
in polLqueue; reset retry 
count; send POLL to node at 
head of polLqueue; start 
RSP_TIMEOUT timer 


BUSY 


RI]*sY WAFT 


hilt fttf KprninAC ovoilohln 


ocna rvjLL. co nooe at neaa ot 
polLqueue; start 
RSP_TIMEOUT timer 


DT TC V 




n ATA fptaiua^ 


jcnu MUCLl 


oUoY_WAJT 




EOD received 


Send WFP; insert node in 
polLqueue 


BUSY.WAIT 




ENQ received; entry for 
source node is in the SEQ 

blalC UIOIC 


oend CLcAK; tluso 


BUSY_WAIT 




ENQ received; no entry for 
source noae in me oci^ state 
table 


Send REJECT; flush 


BUSY.WAIT 




ENO receiverf firnm nrtivf* 

^ IM>WlYVU 11 UU1 UbllVC 

node; ho queued nodes 


S*»nri RFFFPT • finch 






RFP received 


Send WFP; insert node in 
polLqueue 


BUSY_WAIT 




buffer becomes available 


Send POLL to active node; 
start RSP.TIMEOUT timer 


BUSY 



State Machines for Frame SEQ Control. 

All unicast MAC data frames arc sequenced with a 1-bit sequence number (SEQ). The sequence number 
is used to detect lost data frames and duplicate data frames. 

The MAC entity in each node must maintain transmit and receive SEQ state tables for unicast messages. 
The receive SEQ state table contains an entry for each active MAC source node. The transmit SEQ suite 
table contains an entry for each active destination node. Each entry consists of a 1-bit SEQ state variable 
and a network address. Only unicast command frames affect state table entries. As a rule, a receive 
table entry should be discarded before the counterpart transmit table entry (i.e. in another node) is 
discarded. Receive SEQ state table entries need only be kept long enough to ensure that retransmitted 
duplicates are not mistaken for valid frames. This implies that receive table entries must be kept for a 
period longer than the maximum transmit retry time for a single frame. An entry in the transmit SEQ 
state table can be kept until the space is required for a new entry. Strict state timing is not required 
because a transmitter, without a table entry for a potential receiver, can determine the state of a receiver, 
with an RFP frame, before transmitting data frames. Also, note that the MAC layer does not provide a 
reliable service. Lost frames and duplicates are detected by higher layers. 
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The SEQ state machine descriptions below specify how entries in the SEQ state tables are maintained. 
Note that "poll" is used to denote any poll frame ( i.e. POLL. WFP, CLEAR, or REJECT) and "data"' is 
used to denote any data frame (i.e. DATA or EOD). Specific frame types are always m upper case. 

Receive SEQ Control State Machine. 

SEQ State descriptions: 

ACCEPT J) - the receiver expects the next DATA or EOD packet to have a SEQ number of 0. 

ACCEPT. 1 - the receiver expects the next DATA or EOD packet to have a SEQ number of I. 

ACCEPT.AN Y - the receiver will accept a DATA or EOD packet with a SEQ number of 0 or I . 

The MAC receiver caches receive SEQ state variables for active external source nodes. The variable air 
be set to one of three states listed above. A state of ACCEPT.ANY applies to all nodes which do not 
have entries in the receiver's SEQ state table. The receiver sets the SEQ bit in a poll frame to denote the 
next frame that the receiver expects. 



II State 


Event 


Action 


Next State 
ACCEPT ANY 


ALLcr l_AiN Y 


Receive RFP/ENQ 


Return poll 0 




Receive data 0 


Accept frame and return poll 
1 


ACCEPT.l 




Receive data 1 


Accept frame and return poll 

0 


ACCEPT J) 




Receive data 0, no buffer 


Discard frame and return 
WFPO 


ACCEPT J) 




Receive data l f no buffer 


Discard frame and return 
WFP 1 


ACCEPT. 1 


ACCEPT.O 


Receive RFP/ENO 


Return poll 0 


ACCEPT J) 




Receive data 0 


Accept frame and return poll 
1 


ACCEPT. 1 




Receive data 1 


Discard frame and return 
pollO 


ACCEPT 0 




Receive data 0, no buffer 


Discard frame and return 
WFPO 


ACCEPT.O 




State timeout 


Delete state entry 


ACCEPT ANY 


ACCEPT. 1 


Receive RFP/ENO 


Return poll 1 


ACCEPT I 




Receive data 1 


Accept frame and return poll 

0 


ACCEPT.O 




Receive data 0 


Discard frame and return 
poll 1 


ACCEPT. 1 




Receive data 1, no buffer 


Discard frame and return 
WFPI 


ACCEPT.l 




State timeout 


Delete state entry 


ACCEPT ANY 
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Transmit SEQ Control State Machine. 

SEQ State descriptions: 

SEND J) - the transmitter sends the current data frame with a SEQ number of 0 and expects a POLL or 
CLEAR with a SEQ number of 1 . 

SENIM - the transmitter sends the current data frame with a SEQ number of 1 and expects a POLL or 
CLEAR with a SEQ number of 0. 

UNKNOWN - the transmitter must send an RFP or ENQ frame to determine the SEQ state of the 
receiver. 

The MAC transmitter maintains a transmit SEQ suite variable per external node. The transmitter sets the 
SEQ field in DATA and EOD frames to the value of the transmit SEQ state variable. The state variable 
can be in one of the three states listed above. The UNKNOWN state applies to all nodes which do not 
have entries in the transmitter's state table. If the state is UNKNOWN, the transmitter must send an RFP 
or ENQ frame, to determine the SEQ state of the receiver, before sending a data frame. 

The SEQ field in a poll frame denotes the next data frame expected. Each time a poll frame is received 
the transmit SEQ state variable, associated with the source of the poll frame, is set to the value of the poll 
frame s SEQ field. A "current pointer" points to the current data frame in a bracket of data frames. The 
current pointer is advanced if the current data frame has been transmitted with a SEQ field value of 0( 1) 
and a poll frame is received with a SEQ field value of 1(0). 

On radio links, the SEQ state is set to UNKOWN as soon as the transmission of a bracket of frames is 
completed. 



Network Constants. 

WFPJTIMEOUT = 1 second, is the time that a node remains in a quiet state waiting for a POLL frame 
idter a WFP frame is received. 

MAX .PKT.SIZE = 800 bytes, is the maximum size of a bridging layer packet including bridging header 
characters. 

R_MAX_FRAME_SIZE = 100 bytes, is the maximum size of a MAC layer frame on the spread spectrum 
radio link, not including MAC header and framing characters. 

W_MAX.FRAME.SIZE = MAX.PKT.SIZE, is the maximum size of a MAC layer frame on the RS485 
LAN, not including MAC header and framing characters. 

W_MAX.SHORT.FRAME.SIZE » 200 bytes, is the maximum size of a MAC layer frame which can be 
transmitted without first sending a RFP frame on the RS485 LAN. 

W.SLOT.SIZE = 50 microseconds, is the CSMA slot size for the RS485 LAN. 

W JNTERFRAME.GAP = 200 microseconds, is the maximum interfame gap time for the RS485 LAN. 

W JDLE.TIME = WJNTERFRAMEJ3AP + W.SLOT.SEE + 50 microseconds, is the CSMA idle 
time on the RS485 LAN. 
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R_SLOT_SIZE = 1000 microseconds, is the LBT slot size on the spread spectrum radio link. 

R JNTERPOLL_GAP = 5000 microseconds, is the interpoil gap time on the spread spectrum radio link. 

R JDLE.TIME = RJNTERPOLL_GAP, is the LBT idle time on the spread spectrum radio link. 



Channel access algorithms. 

The CSMA/CA channel access algorithm used on the RS485 LAN differs from the LBT algorithm for 
radio links because of the hidden terminal factor in the radio network. 

CSMA/CA summary: 

The p-persisient CSMA/CA algorithm forces all nodes to detect an idle channel for one CSM A idle time 
unit, where a CSM A idle time unit is greater than the interframe gap time, before the channel is 
considered free. If a node initially detects a free channel, it can transmit immediately. If a node detects a 
busy channel, it listens to the channel until it becomes free. When the channel becomes free, at that 
point, time is divided into p CSMA slots. The node selects on of the p slots, say i, at random. If the 
channel is idle for the first i-1 slots, then the node will transmit in slot i. If the channel becomes busy in 
one of the first i- 1 slots, the process is repeated. If an expected response is not received, a node will 
choose a number, i, between I and p, and will delay for i CSMA slots before re-executing the CSMA 
algorithm to retransmit. The number of backoff slots, p. is given as an increasing function of the number 
of missed responses and busy channel detections. 

LBT/BP summary: 

The LBT algorithm functions as a pure CSMA algorithm when the channel is lightly loaded. A channel 
is allowed to transmit as soon as an idle channel is detected. CSMA is never used for retransmissions. 
When the channel is moderately to heavily loaded, the LBT algorithm forces all nodes to detect an idle 
channel for at least one LBT idle time unit, where an LBT idle time unit is greater than the interpoil gap 
time, before the channel is considered free. If a node initially detects a free channel, it can transmit 
immediately. If a node detects a busy channel, it listens to the channel until it becomes free. When the 
channel becomes free, at that point, time is divided into p LBT slots. The node selects on of the p slots, 
say i, at random. If the channel is idle for the first i- 1 slots, then the node will transmit in slot i. If the 
channel becomes busy in one of the first i-1 slots, the process is repeated. If an expected response is not 
received, a node will choose a number, i, between 1 and p, and will delay for i LBT slots before re- 
executing the LBT algorithm to retransmit The number of backoff slots, p, is given as an increasing 
function of the number of missed responses and busy channel detections. 



The CSMA/CA algorithm for the RS485 LAN, and the LBT/BP algorithm for spread spectrum radio links 
are both shown in pseudo-code below. 
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LBT/BP algorithm for a transmitter on the radio network. 

BACKOFFJNIT = 20; 
R.RSP.TIMEOUT = R JNTERPOLL.GAP; 
MAX_TX_TRIES = 20; 
MAXJDLE.TRES =50; 

//, rg - functions which return a maximum backoff number based on the input parameter. 
W;iit for a MAC_send call. 

if p_flag is non-zero then 

begin 1 

select a random number, i, between 0 and BACKOFFJNIT; 

SLOTJ3FFSET =i-R_SLOT_SIZE; 
end 
else 

SLOT_OFFSET=0 ; 

TX_RETRIES=0; 
IDLE_R£TRIES=0; 

while TX.RETRIES < MAX_TX_TRIES and IDLE.RETRIES < MAXJDLEJTRIES and not OK do 
begin 
OK=False; 

detect an idle channel for SLOT_OFFSET+R_IDLE_TIME time units; 
SLOT_OFFSET=0; 
if channel is idle then 
begin 
send_frame; 

if a return priority response is expected then 
begin 

wait for response or R_RSP_TIMEOUT timeout; 
if a valid response has been received then 

OK=True; 
else (assume a collision has occurred) 
begin 

TX_RETRIES=TX - RETRIES+ 1 ; 

select a random number, j, between 0 and r/CTX.RETRIES); 
SLOT_OFFSET=j-R_SLOT_SIZE; 

end 
end 
end 

else (the channel is not idle) 

begin 

wait until the channel is idle; 
IDLE_RETRIES= IDLE.RETRIES+ 1 ; 

select a random number, k ( between 0 and /^<IDLE_RETRIES); 
SLOT.OFFSET =k-R_SLOT_SIZE; 



end 
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CSMA/CA algorithm for a transmitter on the RS485 LAN. 

BACKOFF JNIT = 20; 
W_RSP_TIMEOUT =1 millisecond; 
MAX JTX .TRIES = 20; 
MAXJDLE.TRIES =50; 

wf y and wf? - functions which return a maximum backoff number based on the input parameter. 
Wait for a MAC.send call. 

if p_flag is non-zero then % 
begin 

select a random number, i, between 0 and BACKOFFJNIT; 

SLOT.OFFSET =i-W_SLOT_SIZE; 
end 
else 

SLOT_OFFSET=0 ; 

TX_RETRIES=0; 
IDLE_RETRIES=0; 

while TX.RETREES < MAX.TX JTRIES and IDLEJtETRIES < MAX.IDLE.TRIES and not OK do 
begin 
OK=False; 

detect an idle channel for SLOTJDFFSET+W IDLE TIME time units; 
SLOT_OFFSET=0; 
if channel is idle then 
begin 
send_frame; 

if a return priority response is expected then 
begin 

wait for response or W_RSP_TIMEOUT timeout; 
if a valid response has been received then 

OK=True; 
else (assume a collision has occurred) 
begin 

TX_RETRIES=TX_RETRIES+1; 

select a random number, j, between 0 and h/(TX_RETRIES); 
SLOT_OFFSET=j-W_SLOT_SIZE; 



end 

else (the channel is not idle) 
begin 

wait until the channel is idle; 
IDLE_RETRIES=IDLE_RETRIES+ 1 ; 

select a random number, k, between 0 and h^IDLE_RETRIES); 
SLOT_OFFSET =k-W_SLOT_SIZE; 



end 



end 



end 
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Media Access Framing. 

All frames must be preceded with a preamble which is necessary for bit and character synchronization. 

SST RF frame preamble: 6 to 8 flag bytes (hex 7E). 

SST RF frame trailer: I flag byte (hex 7E) 

RS485 LAN frame preamble: I to 6 flag bytes (hex 7E). 

The preamble is defined in addition to the flag start-of-frame delimiter. For example, frames on the 
RS485 LAN must begin with 2 to 7 flag bytes. The preamble is required for receiver synchronization. 

Line Turnaround Timing. 



SST RF turnaround timing. 

A transmitting device on an RF link must be in receive mode and begin training less than 75 
microseconds after shifting the last bit of the trailing flag byte of a unicast frame onto the link to 
guarantee that a response will not be lost 

A receiver on the RF link must wait at least 75 microseconds, after receiving the end-of-frame flag byte 
in a unicast command frame, before transmitting the last 5 bytes in the preamble of the response frame. 
Fast devices can begin transmitting sooner by adding extra flag byte(s) to the beginning of the response 
frame. Since each character, at 192 Kbps, occupies 41.7 microseconds, an 8-byte preamble is sufficient 
to remove the entire 75 microsecond wait time constraint The first byte in the preamble must be sent 
within 200 microseconds. 



RS485 LAN turnaround timing. 

A transmitting device on the wired RS485 LAN must be in receive mode less than 75 microseconds alter 
shifting the last bit of the end-of-frame flag byte onto the link in a unicast frame. Note that this time 
allows approximately 35 microseconds for transmitting a 16-bit abort sequence and 40 microseconds for 
the line turnaround. 

A receiver on the wired backbone must wait at least 75 microseconds, after receiving the end-of-frame 
flag byte in a unicast frame, before transmitting the last byte in the preamble of the response frame. 
Since each character, at 460.8 Kbps, occupies 17.4 microseconds, a 5-byte preamble is suf ficienct to 
remove the entire 75 microsecond wait time constraint The first byte in the preamble must be sent 
within 200 microseconds. 
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Introduction. 

This document describes the physical characteristics of communications links used by devices in the SST 
network. Medium access techniques mentioned in this document are further defined in the MAC layer 
specification. 



Communication Link Types. 

Six physical communication link types have been defined for devices in the SST network: 

1 ) Direct-sequenced Spread Spectrum Radio. 

2) DEEE802.3. 

3) RS485 LAN. 

4) RS485 Passive Bus. 

5) RS232 Point-to-point 

6) V.35 

(In addition, multiple RS422 links can be used to control and communicate with UHF base stations which 
coexist in the SST network; however the UHF base stations are not considered as part of the SST 
network.) 

Only the first three link types are used for communications within the SST network. The passive bus link 
type is used for off-line batch communications to Norand devices. RS232 is used for communications 
with various devices, including host computers, printers, etc. RS232, V.35 and 802.3 can all be used to 
provide a controller-to-host-computer link. 



Direct -sequenced Spread Sprectrum Interface. 

Spread spectrum radio provides wireless communications for online terminals in a mobile environment. 
Spread spectrum radio links are also used to extend the range of wired radio base stations. The wireless 
base station option facilitates ease of installation and changes in base station topology. 

The spread spectrum channel frequency is 902 to 928 mhz. 
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IEEE 802.3 (ethernet) Interface. 

The IEEE 802.3 interface provides a LAN industry standard backbone channel for the Norand SST 
network. Controllers and/or base stations can be distributed, as required, on an 802.3 LAN to provide 
radio coverage for spread spectrum terminals. A Norand proprietary wired backbone is not required. In 
addition, an 802.3 LAN can provide the link to a host computer. 

802.3 support is implemented with an optional LAN interface module, available on controllers and high- 
end base stations. Each device which supports the 802.3 interface has a twisted-pair compatible RJ45^ 
connector, and a thin coaxial cable compatible BNC connector. Support for thick coaxial cable networks 
must be provided with an off-the-shelf thin-to-thick adaptor module. 

The EEE 802.3 standard is defined in the ISO 8802-3 standard. 



The RS485 LAN or type I interface provides an inexpensive medium-speed wired backbone network for 
devices in the SST system. The RS485 LAN is designed to minimi™ delay for sporadic transaction- 
oriented communications in a, primarily, online environment; however, efficient batch communications 
is also supported on the backbone. 

Type 1 network characteristics are listed below: 

- LAN architecture; 

- EIA RS485 physical link. 

- 460.8 Kbps link speed. 

- Bit-synchronous data link protocol. 

- FM0 data/clock encoding scheme. 

- Access to the link is through p-persistent CSMA hardware and software. 

- Link terminations may be AC coupled. 

- Up to 32 devices are allowed per LAN link segment before a repeater is required. 

- Link segment lengths up to 1000 feet are allowed before a repeater is required. 

- A collision avoidance mechanism is provided for acknowledgments and batch 
traffic. 

The type 1 LAN standard is hierarchical in the sense that all type 1 devices must also support the type 2 
interface described below. 

The 460.8 Kbps standard was chosen because: 

- 460.8 is an even multiple of conventional baud rates (i.e. 48 x 9600). 

- The 230.4 Apple Local talk standard can be achieved by simply dividing the rate by two. 

- A Zilog 8 Mhz 8530 SCC with a 7.3728 Mhz PCLK can achieve the 460.8 Kbps rate (FM0 encoding or 
asynchronous) by gating PCLK to the receive clock input. The 7.3728 Mhz PCLK is required to achieve 
conventional baud rates, up to 1 15.2 Kbps, with the 8530 baud rate generator. Many off-the-shelf 
communications products are implemented with the 8530 chip. 



RS485 LAN (type 1) Interface. 



RS485 Passive Bus (type 2) Interface. 
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The RS485 passive bus interface is designed to reduce contention tor batch communications with devices 
in the SST network and existing DSD terminals. The type 2 interface provides a' passive bus tor 
tnulutlropped terminals. A master controller device regulates access to the bus by slave terminal devices. 

Devices on the RS485 passive bus are not "online" in the SST network. Access to a host computer is 
through an RS485 port on a controller device. 



Type 2 network characteristics are listed below: 



- Bus architecture. 

- EIA RS485 physical link. 

- 1 15.2 Kbps link speed. 

- Access to the link is directed by a "master" controller. 

• The access method is essentially TDM. A single device owns part of the channel for an entire file 
transfer session. 

- NRZ asynchronous data encoding. 

- Up to 32 devices per link segment are allowed before a repeater is required. 

- Link segment lengths up to 1000 feet are allowed before a repeater is required. 

- Link terminations are DC coupled. 



The 1 15.2 Kbps asynchronous standard was chosen because: 



- 1 15.2 is an even multiple of conventional baud rates (i.e. 12 x 9600). 

- The 1 15.2 Kbps speed can be implemented with an interrupt driven or polled UART on slower devices. 

- 4000 DSD terminals are capable of 1 15.2 Kbps asynchronous RS485 communications. 



RS232 Point-to-point (type 3) Interface. 

The RS232 type 3 interface is required to interface with off-the-shelf RS232 devices, host computers, and 
existing Norand RS232 equipment (i.e. printers). RS232 devices must support link speeds up to 38.4 
Kbps. Type 1 devices should support bit-synchronous RS232 communications. All devices must support 
asynchronous RS232 communications. 
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Example 1. 

Figure 1.1 illustrates the use of some of the physical link types described above. 



HOST 




figure 1.1 



Example 2. 

Figure 1.2 illustrates how an 802.3 LAN can be used as the backbone in an SST network. Note that it is 
possible to intermix 802.3 and RS485 links in the same SST network. 
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figure 1.2 
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